From owner-atom-syntax@mail.imc.org Mon Jan 3 13:10: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 NAA21277 for ; Mon, 3 Jan 2005 13:10: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 j03HnZ0f047164; Mon, 3 Jan 2005 09:49: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 j03HnZP3047163; Mon, 3 Jan 2005 09:49:35 -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 j03HnYU4047157 for ; Mon, 3 Jan 2005 09:49:34 -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 j03HnbVu017761 for ; Mon, 3 Jan 2005 10:49:37 -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 <0I9R002IR5IOYJ@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 03 Jan 2005 10:49:37 -0700 (MST) Received: from [192.168.1.37] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9R0058D5IOUK@mail.sun.net> for atom-syntax@imc.org; Mon, 03 Jan 2005 10:49:36 -0700 (MST) Date: Mon, 03 Jan 2005 09:50:38 -0800 From: Tim Bray Subject: Happy New Year! To: "'Atom WG'" 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 Pardon my absence, most of December vanished down 2 or 3 different rat-holes. I'll be talking to Paul later today; it's time to get the Atom work back in high gear... I sense a finish line. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 3 13: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 NAA21359 for ; Mon, 3 Jan 2005 13: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 j03Hx4oN052856; Mon, 3 Jan 2005 09: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 j03Hx4c0052854; Mon, 3 Jan 2005 09:59: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-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 j03Hx2WS052796 for ; Mon, 3 Jan 2005 09:59:02 -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 j03Hx5dt025905 for ; Mon, 3 Jan 2005 10:59:05 -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 <0I9R002G85YHYJ@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 03 Jan 2005 10:59:05 -0700 (MST) Received: from [192.168.1.37] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9R005UQ5YGUN@mail.sun.net> for atom-syntax@imc.org; Mon, 03 Jan 2005 10:59:05 -0700 (MST) Date: Mon, 03 Jan 2005 10:00:07 -0800 From: Tim Bray Subject: Re: Yahoo and "Media RSS" In-reply-to: <1f2ed5cd0412161300632b6f7a@mail.gmail.com> To: Danny Ayers Cc: Graham , Sam Ruby , Atom WG Message-id: <4D4BB479-5DB1-11D9-B0A7-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: <200412161702.CDH87099@ms8.netsolmail.com> <1f2ed5cd04121610092c64752f@mail.gmail.com> <41C1EA79.2070508@intertwingly.net> <1f2ed5cd0412161212122e7fc8@mail.gmail.com> <1f2ed5cd0412161300632b6f7a@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Dec 16, 2004, at 1:00 PM, Danny Ayers wrote: > The RSS 2.0 spec says: > "A RSS feed may contain elements not described on this page, only if > those elements are defined in a namespace." > but is (as far as I can see) silent on attributes, so perhaps the > Yahoo material is perfectly valid, as well as constructs like: > > Yep. I suppose, for clarity, that the 2.0 spec should have said "may contain elements not described on this page, and those elements may have attributes in no namespace, but the such elements must be in a namespace". But I think that's the default understanding. -Tim From owner-atom-syntax@mail.imc.org Tue Jan 4 04:56: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 EAA28016 for ; Tue, 4 Jan 2005 04:56: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 j049eEN2023402; Tue, 4 Jan 2005 01:40: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 j049eErP023401; Tue, 4 Jan 2005 01:40:14 -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 j049eDfK023326 for ; Tue, 4 Jan 2005 01:40:14 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 53607 invoked by uid 17064); 4 Jan 2005 09:40:04 -0000 Received: from unknown (HELO [192.168.0.7]) ([193.251.47.184]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 4 Jan 2005 09:40:04 -0000 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <8E2B8795-5E34-11D9-8C3F-000A95D9FA7A@bblfish.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "'Atom WG'" From: Henry Story Subject: arbitrary limitations in Person Date: Tue, 4 Jan 2005 10:39:40 +0100 X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I was just looking closely at the atom:Person class [1] and found some pretty arbitrary limitations: - why should a Person only have one e-mail address? - why should a Person only have one associated url? It seems to me that one should follow the principle: only impose limitations that are proven to be necessary. Here they seem both unnecessary and counterintuitive. Henry [1] http://ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub- format-03.txt From owner-atom-syntax@mail.imc.org Tue Jan 4 05:13: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 FAA29400 for ; Tue, 4 Jan 2005 05:13: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 j04A5Mer036739; Tue, 4 Jan 2005 02:05: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 j04A5MP5036738; Tue, 4 Jan 2005 02:05:22 -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 j04A5KV2036493 for ; Tue, 4 Jan 2005 02:05:21 -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, 4 Jan 2005 21:04:33 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 04 Jan 2005 21:04:49 +1100 Subject: Re: arbitrary limitations in Person From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <8E2B8795-5E34-11D9-8C3F-000A95D9FA7A@bblfish.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/1/05 8:39 PM, "Henry Story" wrote: > - why should a Person only have one associated url? any objections to using atom:link here? (other than generic objections to atom:link, that is) e. From owner-atom-syntax@mail.imc.org Tue Jan 4 08:02: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 IAA08274 for ; Tue, 4 Jan 2005 08:02: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 j04CoT0J043222; Tue, 4 Jan 2005 04:50: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 j04CoTbu043221; Tue, 4 Jan 2005 04:50:29 -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 j04CoSsn043209 for ; Tue, 4 Jan 2005 04:50:28 -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 1F3324F270; Tue, 4 Jan 2005 07:50:28 -0500 (EST) Message-Id: <6.0.0.20.2.20050104215019.04300f90@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 04 Jan 2005 21:50:47 +0900 To: Henry Story , "'Atom WG'" From: Martin Duerst Subject: Re: arbitrary limitations in Person In-Reply-To: <8E2B8795-5E34-11D9-8C3F-000A95D9FA7A@bblfish.net> References: <8E2B8795-5E34-11D9-8C3F-000A95D9FA7A@bblfish.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 I was asking myself the same questions when I was recently reading the atom format spec. Regards, Martin. At 18:39 05/01/04, Henry Story wrote: > >I was just looking closely at the atom:Person class [1] and found some >pretty arbitrary limitations: > - why should a Person only have one e-mail address? > - why should a Person only have one associated url? > >It seems to me that one should follow the principle: only impose >limitations that are proven to be necessary. Here they seem both >unnecessary and counterintuitive. > >Henry > >[1] >http://ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub- format-03.txt > From owner-atom-syntax@mail.imc.org Tue Jan 4 09:26: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 JAA13709 for ; Tue, 4 Jan 2005 09:26: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 j04E3ths045547; Tue, 4 Jan 2005 06:03: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 j04E3t8Z045543; Tue, 4 Jan 2005 06:03:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j04E3sIk045437 for ; Tue, 4 Jan 2005 06:03:55 -0800 (PST) (envelope-from brett.lindsley@labs.mot.com) Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j04E5hfL004785 for ; Tue, 4 Jan 2005 07:05:43 -0700 (MST) Received: from labs.mot.com (udomsvc2.labs.mot.com [173.23.250.2]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id j04E3q61031806 for ; Tue, 4 Jan 2005 08:03:53 -0600 Received: from udomsvc5.labs.mot.com (udomsvc5.labs.mot.com [173.23.250.5]) by labs.mot.com (MotLabs Smoke & Mirrors) with ESMTP id j04E3qtv014125 for ; Tue, 4 Jan 2005 08:03:52 -0600 (CST) Received: from labs.mot.com by ims1.labs.mot.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0I9S004FWPQGN3@ims1.labs.mot.com> for atom-syntax@imc.org; Tue, 04 Jan 2005 08:03:52 -0600 (CST) Date: Tue, 04 Jan 2005 08:03:52 -0600 From: Brett Lindsley Subject: Re: arbitrary limitations in Person Cc: "'Atom WG'" Message-id: <41DAA248.6090907@labs.mot.com> Organization: Mot Labs MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <8E2B8795-5E34-11D9-8C3F-000A95D9FA7A@bblfish.net> <6.0.0.20.2.20050104215019.04300f90@localhost> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT A while ago I wrote a Pace (but I can't seem to find it, maybe I didn't finish it, it was a while ago...) on using a vCard for the Person. vCards are pretty common and have some XML formats that would fit in to the current spec. Any interest? Brett Lindsley, Motorola Labs Martin Duerst wrote: > > I was asking myself the same questions when I was recently reading > the atom format spec. > > Regards, Martin. > > At 18:39 05/01/04, Henry Story wrote: > > > >I was just looking closely at the atom:Person class [1] and found some > >pretty arbitrary limitations: > > - why should a Person only have one e-mail address? > > - why should a Person only have one associated url? > > > >It seems to me that one should follow the principle: only impose > >limitations that are proven to be necessary. Here they seem both > >unnecessary and counterintuitive. > > > >Henry > > > >[1] > >http://ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub- > format-03.txt > > From owner-atom-syntax@mail.imc.org Tue Jan 4 10:27: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 KAA19113 for ; Tue, 4 Jan 2005 10:27: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 j04F6cNa076832; Tue, 4 Jan 2005 07:06: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 j04F6cIc076831; Tue, 4 Jan 2005 07:06:38 -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 j04F6Xam076808 for ; Tue, 4 Jan 2005 07:06:33 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 39706 invoked by uid 17064); 4 Jan 2005 15:06:36 -0000 Received: from unknown (HELO [192.168.0.7]) ([193.251.47.184]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 4 Jan 2005 15:06:36 -0000 In-Reply-To: <41DAA248.6090907@labs.mot.com> References: <8E2B8795-5E34-11D9-8C3F-000A95D9FA7A@bblfish.net> <6.0.0.20.2.20050104215019.04300f90@localhost> <41DAA248.6090907@labs.mot.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2C5B8C0A-5E62-11D9-8C3F-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: atom-owl@googlegroups.com From: Henry Story Subject: Re: arbitrary limitations in Person Date: Tue, 4 Jan 2005 16:06:12 +0100 To: "'Atom WG'" , Brett Lindsley X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I think that the simplicity of atom:Person is fine. I have not checked this out carefully, but it should be possible to map it quite easily to foaf:Agent[1]. If one specified the following mappings: - atom:Person is a subclass of foaf:Agent - atom:uri is a super property of foaf:weblog - atom:email is the sub property as foaf:mbox then we can have an atom segment represented in triples as _someEntry --- isa ---> |----------author---> _somePerson ---isa-------> | |------------isa-------> ... |-----atom:name-------->"John Doe"^^xsd:String |-----atom:email-------> |-----foaf:gender------>"male"^^xsd:String |----foaf:aimChatID---->"aim:johndoe"^^xsd:String so I think this translates into the following Atom xml .... John Doe john@doe.com male aim:johndoe .... In fact there is a little hitch in the mapping between atom:email and foaf:mbox that I have just noticed. foaf:mbox has as object a mailto uri. Perhaps this would be a good idea for a improvement to the spec? Henry Story [1] http://xmlns.com/foaf/0.1/#term_Agent (In fact I think that we should use Agent instead of Person, as it is quite possible that robots, or multi-person organizations be creating blog entries or feeds. On 4 Jan 2005, at 15:03, Brett Lindsley wrote: > > A while ago I wrote a Pace (but I can't seem to find it, maybe I > didn't finish > it, it was a while ago...) on using a vCard for the Person. vCards are > pretty > common and have some XML formats that would fit in to the current spec. > Any interest? > > Brett Lindsley, Motorola Labs > > Martin Duerst wrote: > >> >> I was asking myself the same questions when I was recently reading >> the atom format spec. >> >> Regards, Martin. >> >> At 18:39 05/01/04, Henry Story wrote: >> > >> >I was just looking closely at the atom:Person class [1] and found >> some >> >pretty arbitrary limitations: >> > - why should a Person only have one e-mail address? >> > - why should a Person only have one associated url? >> > >> >It seems to me that one should follow the principle: only impose >> >limitations that are proven to be necessary. Here they seem both >> >unnecessary and counterintuitive. >> > >> >Henry >> > >> >[1] >> >http://ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub- >> format-03.txt >> > > > From owner-atom-syntax@mail.imc.org Tue Jan 4 10:45: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 KAA20450 for ; Tue, 4 Jan 2005 10:45: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 j04FWGZW085909; Tue, 4 Jan 2005 07:32: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 j04FWG0f085908; Tue, 4 Jan 2005 07:32:16 -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 j04FWGED085895 for ; Tue, 4 Jan 2005 07:32:16 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 61731 invoked by uid 17064); 4 Jan 2005 15:32:18 -0000 Received: from unknown (HELO [192.168.0.7]) ([193.251.47.184]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 4 Jan 2005 15:32:18 -0000 In-Reply-To: <2C5B8C0A-5E62-11D9-8C3F-000A95D9FA7A@bblfish.net> References: <8E2B8795-5E34-11D9-8C3F-000A95D9FA7A@bblfish.net> <6.0.0.20.2.20050104215019.04300f90@localhost> <41DAA248.6090907@labs.mot.com> <2C5B8C0A-5E62-11D9-8C3F-000A95D9FA7A@bblfish.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-owl@googlegroups.com, "'Atom WG'" From: Henry Story Subject: Re: arbitrary limitations in Person Date: Tue, 4 Jan 2005 16:31:53 +0100 To: Brett Lindsley X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Oh. I should have mentioned how I see this being able to relate to vcards. There is an rdf ontology for vcards on SchemaWeb [1]. It is a little odd because it assigns names, addresses and other properties to vcards instead of to people. But it would be easy to add a property from a foaf:Person to a vcard named vcard, that would then contain all that info, something like _someEntry --- isa ---> |----------author---> _somePerson ---isa-------> | |------------isa-------> ... |-----atom:name-------->"John Doe"^^xsd:String |-----atom:email-------> |-----foaf:gender------>"male"^^xsd:String |----foaf:aimChatID---->"aim:johndoe"^^xsd:String |----xxx:vcard--------->_avcard ---isa----> |---vcard:familyName-->"Doe" ... If you draw me a diagram as above with a good vcard ontology that you like, I'll go through the process of step by step showing how one can get to an atom xml format from first principles. Henry Story [1] http://www.schemaweb.info/schema/SchemaDetails.aspx?id=215 On 4 Jan 2005, at 16:06, Henry Story wrote: > > I think that the simplicity of atom:Person is fine. I have not checked > this out carefully, but it should be possible to map it quite easily > to foaf:Agent[1]. If one specified the following mappings: > - atom:Person is a subclass of foaf:Agent > - atom:uri is a super property of foaf:weblog > - atom:email is the sub property as foaf:mbox > > then we can have an atom segment represented in triples as > > _someEntry --- isa ---> > |----------author---> _somePerson ---isa-------> > | |------------isa-------> > ... |-----atom:name-------->"John > Doe"^^xsd:String > > |-----atom:email-------> > |-----foaf:gender------>"male"^^xsd:String > > |----foaf:aimChatID---->"aim:johndoe"^^xsd:String > > so I think this translates into the following Atom xml > > > .... > > John Doe > john@doe.com > male > aim:johndoe > > .... > > > In fact there is a little hitch in the mapping between atom:email and > foaf:mbox that I have just noticed. foaf:mbox has as object a mailto > uri. Perhaps this would be a good idea for a improvement to the spec? > > > Henry Story > > > [1] http://xmlns.com/foaf/0.1/#term_Agent (In fact I think that we > should use Agent instead of Person, as it is quite possible that > robots, or multi-person organizations be creating blog entries or > feeds. > > On 4 Jan 2005, at 15:03, Brett Lindsley wrote: > >> >> A while ago I wrote a Pace (but I can't seem to find it, maybe I >> didn't finish >> it, it was a while ago...) on using a vCard for the Person. vCards >> are pretty >> common and have some XML formats that would fit in to the current >> spec. >> Any interest? >> >> Brett Lindsley, Motorola Labs >> >> Martin Duerst wrote: >> >>> >>> I was asking myself the same questions when I was recently reading >>> the atom format spec. >>> >>> Regards, Martin. >>> >>> At 18:39 05/01/04, Henry Story wrote: >>> > >>> >I was just looking closely at the atom:Person class [1] and found >>> some >>> >pretty arbitrary limitations: >>> > - why should a Person only have one e-mail address? >>> > - why should a Person only have one associated url? >>> > >>> >It seems to me that one should follow the principle: only impose >>> >limitations that are proven to be necessary. Here they seem both >>> >unnecessary and counterintuitive. >>> > >>> >Henry >>> > >>> >[1] >>> >http://ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub- >>> format-03.txt >>> > >> >> > From owner-atom-syntax@mail.imc.org Tue Jan 4 10:48: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 KAA21154 for ; Tue, 4 Jan 2005 10:48: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 j04FcTdH086755; Tue, 4 Jan 2005 07:38: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 j04FcTko086754; Tue, 4 Jan 2005 07:38:29 -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 j04FcTlR086748 for ; Tue, 4 Jan 2005 07:38:29 -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 j04FcVVu016767 for ; Tue, 4 Jan 2005 08:38:31 -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 <0I9S00HQ3U46VQ@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 04 Jan 2005 08:38:30 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9S0055QU45UN@mail.sun.net> for atom-syntax@imc.org; Tue, 04 Jan 2005 08:38:30 -0700 (MST) Date: Tue, 04 Jan 2005 07:38:27 -0800 From: Tim Bray Subject: Re: arbitrary limitations in Person In-reply-to: <8E2B8795-5E34-11D9-8C3F-000A95D9FA7A@bblfish.net> To: Henry Story Cc: "'Atom WG'" 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: <8E2B8795-5E34-11D9-8C3F-000A95D9FA7A@bblfish.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 4, 2005, at 1:39 AM, Henry Story wrote: > > I was just looking closely at the atom:Person class [1] and found some > pretty arbitrary limitations: > - why should a Person only have one e-mail address? > - why should a Person only have one associated url? It does seem to me that this will make an implementor's life a little easier. -Tim From owner-atom-syntax@mail.imc.org Tue Jan 4 11:34: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 LAA24553 for ; Tue, 4 Jan 2005 11:34: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 j04GS8QD093633; Tue, 4 Jan 2005 08:28: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 j04GS8HU093632; Tue, 4 Jan 2005 08:28:08 -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 j04GS7np093626 for ; Tue, 4 Jan 2005 08:28:07 -0800 (PST) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id 310864EFEB; Tue, 4 Jan 2005 11:28:07 -0500 (EST) Date: Tue, 4 Jan 2005 11:28:07 -0500 From: Dan Brickley To: Tim Bray Cc: Henry Story , "'Atom WG'" Subject: Re: arbitrary limitations in Person Message-ID: <20050104162807.GD22265@homer.w3.org> References: <8E2B8795-5E34-11D9-8C3F-000A95D9FA7A@bblfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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-01-04 07:38-0800] > > > On Jan 4, 2005, at 1:39 AM, Henry Story wrote: > > > > >I was just looking closely at the atom:Person class [1] and found some > >pretty arbitrary limitations: > > - why should a Person only have one e-mail address? > > - why should a Person only have one associated url? (s/url/uri/) > It does seem to me that this will make an implementor's life a little > easier. -Tim So long as these Person-descriptions aren't expected to be complete, it seems a reasonable approach. The atom:uri (homepage or weblog) is a reasonable place to go rummaging for more info about the identified Person. While I like the RSS1 flexibility to include more details inline (eg. foaf:workplaceHomepage, for aggregating feeds by employer), it's perfectly reasonable to partition the work differently, and push the flexibility off to other document formats. From an RDF perspective, it would be good to be able to consider the Atom:Person 'uri' and 'email' constructs to be "inverse functional properties"[1]. This is a guarantee that, properly used, these fields should identify "at most one thing" that has any given uri, or any given email. In other words, given any value that has correctly appeared as an Atom:Person url or email, there should be no more than one thing it could possibly be the url or email of. This makes it much easier on aggregators, but to possible annoyance of folks who have communal mailboxes and homepages. Revisiting [3.2: Person Constructs] of http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-03.txt 3.2.3 "atom:email" introduces a redundancy, since 3.2.2 "atom:uri" allows for mailto: URIs. Being able to pick out an email address without doing URL analysis seems worthwhile enough that the redundancy has value. But perhaps a note on this would help: a rough proposal: 3.2.2 NOTE: Although mailto: and other messaging-related URIs are technical in-scope for 3.2.3, the atom:email element SHOULD be used for a Person's email address, instead of using mailto: URIs in the atom:uri element. (Worth noting also that the spec also currently allows two emails to be stored, one as a mailto: in atom:uri, the other as atom:email. But you can't legislate against everything...). If atom:uri and/or atom:email could be used to unambiguously pick out some individual atom:Person, I'd be perfectly happy with the limited inline descriptions Atom allows, particular since namespace'd extensions are permissible. I'm not sure on the current definitions though - "a URI associated with" is loose enough that (for eg.) both Martin and myself could use http://www.w3.org/ without violating the spec. It's the nature of the association that's key. If the association can be specified as uniquely identifying, then aggregators can go rummage around that URI for more FOAF, vCard, XFN etc to flesh out the sparse inline description. At the moment FOAF has two properties somewhat akin to atom:uri, the foaf:homepage and foaf:weblog properties. I've often wondered about a common superproperty (since distinguishing homepages from weblogs is tricky anyway) but just couldn't think of a good name. The simplest fix I can think to propose at the moment is: 3.2.2 s/a URI associated with/a URI uniquely associated with/ ...though I fear "uniquely" might need some more definition, along lines of "Any URI used as the value of an atom:uri element MUST be a URI of a single identifiable entity (Person, corporation or similar entity)." (I make the word "of" do a lot of work here; in FOAF we say "weblog of", "homepage of" which may or may not be close to this WG's thinking). cheers, Dan [1] OWL/RDF jargon. See http://rdfweb.org/mt/foaflog/archives/2003/07/10/12.05.33/ for fairly detailed walk-thru of how this is used in FOAF for identification-via-description. From owner-atom-syntax@mail.imc.org Tue Jan 4 11:35: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 LAA24642 for ; Tue, 4 Jan 2005 11:35: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 j04GMoxi092949; Tue, 4 Jan 2005 08:22: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 j04GMoAX092947; Tue, 4 Jan 2005 08:22:50 -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 j04GMoKj092936 for ; Tue, 4 Jan 2005 08:22:50 -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 2D3F7AD for ; Tue, 4 Jan 2005 08:22:42 -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 j04GMCKB012286 for ; Tue, 4 Jan 2005 08:22:40 -0800 (PST) Date: Tue, 04 Jan 2005 08:22:08 -0800 From: Walter Underwood To: "'Atom WG'" Subject: Re: arbitrary limitations in Person Message-ID: <1BFBA0145BE62ADF6F59FE4F@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: References: <8E2B8795-5E34-11D9-8C3F-000A95D9FA7A@bblfish.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 January 4, 2005 7:38:27 AM -0800 Tim Bray wrote: > On Jan 4, 2005, at 1:39 AM, Henry Story wrote: >> >> I was just looking closely at the atom:Person class [1] and found some >> pretty arbitrary limitations: >> - why should a Person only have one e-mail address? >> - why should a Person only have one associated url? > > It does seem to me that this will make an implementor's life a little easier. -Tim Easier when reading the format, but harder when writing. The user or editor will need to make selections from a richer (probably LDAP/X.500) record to reduce it to this limited format. Why not use inetOrgPerson (RFC 2798)? That should provide the easiest mapping to and from most directories. vCard seems to be a serialization format for directory information, not a data model, so that doesn't really help decide what elements should be in Atom. Using inetOrgPerson also supports: - corporate authors (published by Hewlett-Packard) - Japanese names (givenname/familyname) - nicknames ("Babs Jensen" for "Barbara Jensen") - certificates - postal addresses Last time I was involved in LDAP, inetOrgPerson was widely used: Microsoft, Novell, Netscape/Sun/iPlanet/whatever, and so on. Tim: want to run this by the directory gurus at Sun and get their input? wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Tue Jan 4 11: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 LAA25392 for ; Tue, 4 Jan 2005 11:48: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 j04GeOGm094578; Tue, 4 Jan 2005 08:40: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 j04GeOwM094577; Tue, 4 Jan 2005 08:40:24 -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 j04GeGWR094563; Tue, 4 Jan 2005 08:40:21 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8E2B8795-5E34-11D9-8C3F-000A95D9FA7A@bblfish.net> Date: Tue, 4 Jan 2005 08:40:17 -0800 To: Tim Bray , Henry Story From: Paul Hoffman / IMC Subject: Re: arbitrary limitations in Person 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 7:38 AM -0800 1/4/05, Tim Bray wrote: >On Jan 4, 2005, at 1:39 AM, Henry Story wrote: > >> >>I was just looking closely at the atom:Person class [1] and found >>some pretty arbitrary limitations: >> - why should a Person only have one e-mail address? >> - why should a Person only have one associated url? > >It does seem to me that this will make an implementor's life a >little easier. -Tim But only a little, yet it restricts very common things that people have. Let's get rid of the restriction. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Jan 4 13:40: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 NAA06284 for ; Tue, 4 Jan 2005 13:40: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 j04IROrU069198; Tue, 4 Jan 2005 10: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 j04IRO79069197; Tue, 4 Jan 2005 10:27:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j04IRNlf069184 for ; Tue, 4 Jan 2005 10:27:23 -0800 (PST) (envelope-from brett.lindsley@labs.mot.com) Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j04ITDfL021544 for ; Tue, 4 Jan 2005 11:29:13 -0700 (MST) Received: from labs.mot.com (udomsvc2.labs.mot.com [173.23.250.2]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id j04IRNNx015091 for ; Tue, 4 Jan 2005 12:27:23 -0600 Received: from udomsvc5.labs.mot.com (udomsvc5.labs.mot.com [173.23.250.5]) by labs.mot.com (MotLabs Smoke & Mirrors) with ESMTP id j04IRNtv022731 for ; Tue, 4 Jan 2005 12:27:23 -0600 (CST) Received: from labs.mot.com by ims1.labs.mot.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0I9T004651XMN3@ims1.labs.mot.com> for atom-syntax@imc.org; Tue, 04 Jan 2005 12:27:23 -0600 (CST) Date: Tue, 04 Jan 2005 12:27:22 -0600 From: Brett Lindsley Subject: Re: arbitrary limitations in Person Cc: "'Atom WG'" Message-id: <41DAE00A.7060000@labs.mot.com> Organization: Mot Labs MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <8E2B8795-5E34-11D9-8C3F-000A95D9FA7A@bblfish.net> <6.0.0.20.2.20050104215019.04300f90@localhost> <41DAA248.6090907@labs.mot.com> <2C5B8C0A-5E62-11D9-8C3F-000A95D9FA7A@bblfish.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT I appreciate the interesting discussion although I do appologize for not having sufficient time to keep up with the thread. I think we all have some motion toward a less constraining Person construct with the ability to have more detail (phone number, alternate e-mails, or whatever). Having spent a lot of time with SyncML, (RDF/XML) vCard was the first to pop into my head [1]. Since I am not an authority on the alternatives, I hope the experts can propose something better. Brett Lindsley, Motorola Labs [1] http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ Henry Story wrote: > > Oh. I should have mentioned how I see this being able to relate to > vcards. There is an rdf ontology for vcards on SchemaWeb [1]. It is a > little odd because it assigns names, addresses and other properties to > vcards instead of to people. But it would be easy to > add a property from a foaf:Person to a vcard named vcard, that would > then contain all that info, something like > > > _someEntry --- isa ---> > |----------author---> _somePerson ---isa-------> > | |------------isa-------> > ... |-----atom:name-------->"John > Doe"^^xsd:String > |-----atom:email-------> > |-----foaf:gender------>"male"^^xsd:String > > |----foaf:aimChatID---->"aim:johndoe"^^xsd:String > |----xxx:vcard--------->_avcard > ---isa----> > > |---vcard:familyName-->"Doe" > ... > > If you draw me a diagram as above with a good vcard ontology that you > like, I'll go through the process of step by step showing how one can > get to an atom xml format > from first principles. > > Henry Story > > [1] http://www.schemaweb.info/schema/SchemaDetails.aspx?id=215 > > On 4 Jan 2005, at 16:06, Henry Story wrote: > >> >> I think that the simplicity of atom:Person is fine. I have not >> checked this out carefully, but it should be possible to map it quite >> easily to foaf:Agent[1]. If one specified the following mappings: >> - atom:Person is a subclass of foaf:Agent >> - atom:uri is a super property of foaf:weblog >> - atom:email is the sub property as foaf:mbox >> >> then we can have an atom segment represented in triples as >> >> _someEntry --- isa ---> >> |----------author---> _somePerson ---isa-------> >> | |------------isa-------> >> ... |-----atom:name-------->"John >> Doe"^^xsd:String >> >> |-----atom:email-------> >> |-----foaf:gender------>"male"^^xsd:String >> >> |----foaf:aimChatID---->"aim:johndoe"^^xsd:String >> >> so I think this translates into the following Atom xml >> >> >> .... >> >> John Doe >> john@doe.com >> male >> aim:johndoe >> >> .... >> >> >> In fact there is a little hitch in the mapping between atom:email and >> foaf:mbox that I have just noticed. foaf:mbox has as object a mailto >> uri. Perhaps this would be a good idea for a improvement to the spec? >> >> >> Henry Story >> >> >> [1] http://xmlns.com/foaf/0.1/#term_Agent (In fact I think that we >> should use Agent instead of Person, as it is quite possible that >> robots, or multi-person organizations be creating blog entries or feeds. >> >> On 4 Jan 2005, at 15:03, Brett Lindsley wrote: >> >>> >>> A while ago I wrote a Pace (but I can't seem to find it, maybe I >>> didn't finish >>> it, it was a while ago...) on using a vCard for the Person. vCards >>> are pretty >>> common and have some XML formats that would fit in to the current spec. >>> Any interest? >>> >>> Brett Lindsley, Motorola Labs >>> >>> Martin Duerst wrote: >>> >>>> >>>> I was asking myself the same questions when I was recently reading >>>> the atom format spec. >>>> >>>> Regards, Martin. >>>> >>>> At 18:39 05/01/04, Henry Story wrote: >>>> > >>>> >I was just looking closely at the atom:Person class [1] and found >>>> some >>>> >pretty arbitrary limitations: >>>> > - why should a Person only have one e-mail address? >>>> > - why should a Person only have one associated url? >>>> > >>>> >It seems to me that one should follow the principle: only impose >>>> >limitations that are proven to be necessary. Here they seem both >>>> >unnecessary and counterintuitive. >>>> > >>>> >Henry >>>> > >>>> >[1] >>>> >http://ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub- >>>> format-03.txt >>>> > >>> >>> >>> >> > From owner-atom-syntax@mail.imc.org Tue Jan 4 15:46: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 PAA16924 for ; Tue, 4 Jan 2005 15:46: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 j04KM2Tq091259; Tue, 4 Jan 2005 12:22: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 j04KM2T1091258; Tue, 4 Jan 2005 12:22:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j04KLufO091116 for ; Tue, 4 Jan 2005 12:21:56 -0800 (PST) (envelope-from ga-atom-syntax@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ClvBe-0002mI-00 for ; Tue, 04 Jan 2005 21:21:50 +0100 Received: from corp-fw-main.jabber.com ([207.182.164.14]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 Jan 2005 21:21:50 +0100 Received: from stpeter by corp-fw-main.jabber.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 Jan 2005 21:21:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: atom-syntax@imc.org From: Peter Saint-Andre Subject: Re: Atom Notification Protocol Published Date: Tue, 04 Jan 2005 13:14:43 -0700 Organization: Jabber Software Foundation Lines: 11 Message-ID: References: <2bcdc7c404121613464c0709b9@mail.gmail.com> <200412180742.CEF65051@ms8.netsolmail.com> <2bcdc7c404122311451063df01@mail.gmail.com> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: corp-fw-main.jabber.com User-Agent: MT-NewsWatcher/3.4 (PPC Mac OS X) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In article <2bcdc7c404122311451063df01@mail.gmail.com>, James Snell wrote: > Head elements in the entry have been discussed on the list and are > described here: http://www.intertwingly.net/wiki/pie/PaceHeadInEntry. > AFAIK, The proposal has been accepted and is slated for incorporation > into the draft. Super, thanks. That's quite helpful. It even has a nice XMPP example. :-) Peter From owner-atom-syntax@mail.imc.org Wed Jan 5 03:55: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 DAA13955 for ; Wed, 5 Jan 2005 03:55: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 j058ch6t028606; Wed, 5 Jan 2005 00:38: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 j058chjW028603; Wed, 5 Jan 2005 00:38:43 -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 j058cgJt028330 for ; Wed, 5 Jan 2005 00:38:42 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 12098 invoked by uid 17064); 5 Jan 2005 08:38:36 -0000 Received: from unknown (HELO [192.168.0.6]) ([193.251.47.162]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 5 Jan 2005 08:38:36 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <41DAE00A.7060000@labs.mot.com> References: <8E2B8795-5E34-11D9-8C3F-000A95D9FA7A@bblfish.net> <6.0.0.20.2.20050104215019.04300f90@localhost> <41DAA248.6090907@labs.mot.com> <2C5B8C0A-5E62-11D9-8C3F-000A95D9FA7A@bblfish.net> <41DAE00A.7060000@labs.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <22DE75BF-5EF5-11D9-8C3F-000A95D9FA7A@bblfish.net> From: Henry Story Subject: Re: arbitrary limitations in Person: inverse functional changes Date: Wed, 5 Jan 2005 09:38:12 +0100 To: "'Atom WG'" X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j058cgJt028597 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I would like to add a big +1 for the suggestions given by Dan Brickley in this thread [1]. Those changes are I believe more important than the ones I was suggesting. If we tidy up the spec as suggested so that the property email and uri are clearly intended to be inverse functional, i.e. one such property uniquely identifies a single Person, then it is very easy to extend the Person construct with non atom namespaces elements, be they foaf, vCard or RFC 2798 elements transformed into a schema. That is we need to focus first on making what we have be clearly and correctly extensible. At a later date we can always, as with RSS1.0, specify the more popular extension elements. So my list of priorities ordered by weight: [100] Dan Brickley's suggestions. [2Ø] Perhaps change the name of the Person construct to a more general Agent construct [20] Remove limitation restricting the inverse functional email and uri properties to 1 Do we need a Pace for Dan Brickley's suggestion? Henry Story [1] http://www.imc.org/atom-syntax/mail-archive/msg11872.html On 4 Jan 2005, at 19:27, Brett Lindsley wrote: > I appreciate the interesting discussion although I do appologize for > not having sufficient time to keep up with the thread. I think we all > have some motion toward a less constraining Person construct with the > ability to have more detail (phone number, alternate e-mails, or > whatever). Having spent a lot of time with SyncML, (RDF/XML) vCard was > the first to pop into my head [1]. Since I am not an authority on the > alternatives, I hope the experts can propose something better. > > Brett Lindsley, Motorola Labs > > [1] http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ On 4 Jan 2005, at 19:27, Walter Underwood wrote: > Why not use inetOrgPerson (RFC 2798)? That should provide the easiest > mapping to and from most directories. > > vCard seems to be a serialization format for directory information, not > a data model, so that doesn't really help decide what elements should > be in Atom. From owner-atom-syntax@mail.imc.org Wed Jan 5 04:29: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 EAA15597 for ; Wed, 5 Jan 2005 04: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 j059KhMo093594; Wed, 5 Jan 2005 01:20: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 j059KhsT093593; Wed, 5 Jan 2005 01:20:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mystix.bangor.ac.uk (mystix.bangor.ac.uk [147.143.2.82]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j059KfHO093365 for ; Wed, 5 Jan 2005 01:20:42 -0800 (PST) (envelope-from s.wilson@bangor.ac.uk) Received: from [147.143.202.202] (toomol11 [147.143.202.202]) (authenticated bits=0) by mystix.bangor.ac.uk (8.12.10/8.12.10) with ESMTP id j059IVcQ023005; Wed, 5 Jan 2005 09:18:31 GMT In-Reply-To: <41DAE00A.7060000@labs.mot.com> References: <8E2B8795-5E34-11D9-8C3F-000A95D9FA7A@bblfish.net> <6.0.0.20.2.20050104215019.04300f90@localhost> <41DAA248.6090907@labs.mot.com> <2C5B8C0A-5E62-11D9-8C3F-000A95D9FA7A@bblfish.net> <41DAE00A.7060000@labs.mot.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <402DADBD-5EFB-11D9-8B40-000D9371050C@bangor.ac.uk> Content-Transfer-Encoding: 7bit Cc: "'Atom WG'" From: Scott Wilson Subject: Re: arbitrary limitations in Person Date: Wed, 5 Jan 2005 09:21:59 +0000 To: Brett Lindsley X-Mailer: Apple Mail (2.619) X-UWB-MailScanner-Information: Please contact the ISP for more information X-UWB-MailScanner: Found to be clean X-UWB-MailScanner-SpamCheck: nid sbam/not spam (goddefadwy/whitelisted), SpamAssassin (sgor/score=-5.286, yn ofynnol/required 4.5, autolearn=not spam, ALL_TRUSTED -3.30, AWL 0.61, BAYES_00 -2.60) X-UWB-MailScanner-From: s.wilson@bangor.ac.uk Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit There are plenty of schemas for person data: - FOAF - VCARD - HR-XML - InetOrgPerson - EduPerson - IMSEnterprisePerson - IMSLearnerInformation/BS-8788 - ... etc ... Of all these, FOAF would seem to me to be closest in intent and audience to Atom (even though it does make some odd vocab choices in some places, overall I'm a big fan). I worked on the last two, for my sins! However, rather than turn Atom into an identity spec, I would advise an approach supporting the absolute minimum of identity information within the core spec while allowing the introduction of more detailed information where required from other schemas. So, keep the restrictions as they are, but make sure the practice of including appropriately namespaced elements from FOAF is understood as being a valid way of extending Atom. I think this echoes what Henry posted earlier on this topic. - Scott ========= Scott Wilson Centre For Educational Technology Interoperability Standards (CETIS) Web: http://www.cetis.ac.uk Atom: http://www.cetis.,ac.uk/news.atom Foaf: http://www.cetis.ac.uk/members/scott/foaf.rdf On 4 Jan 2005, at 18:27, Brett Lindsley wrote: > > I appreciate the interesting discussion although I do appologize for > not having sufficient > time to keep up with the thread. I think we all have some motion > toward a less constraining > Person construct with the ability to have more detail (phone number, > alternate e-mails, > or whatever). Having spent a lot of time with SyncML, (RDF/XML) vCard > was the first to > pop into my head [1]. Since I am not an authority on the alternatives, > I hope the experts > can propose something better. > > Brett Lindsley, Motorola Labs > > [1] http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ > From owner-atom-syntax@mail.imc.org Wed Jan 5 16:54: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 QAA22705 for ; Wed, 5 Jan 2005 16:54: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 j05La4Eo082143; Wed, 5 Jan 2005 13: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 j05La4hZ082142; Wed, 5 Jan 2005 13:36: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-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 j05La3G2082056 for ; Wed, 5 Jan 2005 13:36:03 -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 j05La7dt001469 for ; Wed, 5 Jan 2005 14:36:07 -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 <0I9V007YQ5C7BX@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 05 Jan 2005 14:36:07 -0700 (MST) Received: from [192.168.1.40] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9V000EU5AI7R@mail.sun.net> for atom-syntax@imc.org; Wed, 05 Jan 2005 14:36:07 -0700 (MST) Date: Wed, 05 Jan 2005 13:36:06 -0800 From: Tim Bray Subject: Posted PaceEnclosuresAndPix To: "'Atom WG'" 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 There are a couple of areas where we don't quite have feature parity with RSS2.0, this tries to address that: http://www.intertwingly.net/wiki/pie/PaceEnclosuresAndPix -Tim From owner-atom-syntax@mail.imc.org Wed Jan 5 17:34: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 RAA26565 for ; Wed, 5 Jan 2005 17: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 j05MSFa3022902; Wed, 5 Jan 2005 14: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 j05MSFeA022899; Wed, 5 Jan 2005 14:28:15 -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 j05MSEQ6022845 for ; Wed, 5 Jan 2005 14:28:14 -0800 (PST) (envelope-from lavandowska@gmail.com) Received: by wproxy.gmail.com with SMTP id 40so397847wri for ; Wed, 05 Jan 2005 14:28: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:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=r/7Pg/VDdUm4m80lb+7O4+ySUtNAobUdy/KlV3Di96ZFl8PiVCDHITPCNEmKlTjSva76PoU3ul8AAT4BSRon4XR/VL14VN+OTOXUifsyqETjdDuIaFSy2wuRzRFBn5Xs6bqZvYm1Qm77y/jaHZi7iyuVZibhhgBU7tJHNeWL7ec= Received: by 10.54.19.64 with SMTP id 64mr801546wrs; Wed, 05 Jan 2005 14:28:11 -0800 (PST) Received: by 10.54.59.5 with HTTP; Wed, 5 Jan 2005 14:28:11 -0800 (PST) Message-ID: <96d7d77c0501051428125ae064@mail.gmail.com> Date: Wed, 5 Jan 2005 16:28:11 -0600 From: Lance Lavandowska Reply-To: Lance Lavandowska To: Tim Bray Subject: Re: Posted PaceEnclosuresAndPix 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 Actually, I recall this has been discussed previously (providing Enclosure-like support) [1 for an example] which eventually pointed up the PaceLinkRelated[2] which covered much of the same ground. But your proposal raises a few questions/comments on my part: 1) There has been some controversy as to the "arbitrary" restriction of one enclosure per item in RSS. Should we duplicate that restriction? If so, why? 2) Why not have an 'image' link in an entry? I recall discussion of using <content src="..."%gt; or somesuch for graphics, but has a Flikr-like usecase been discussed? Using an 'image' link and regular content seems appropriate. 3) On the 'size' attribute. 'size', 'length' and 'content-length' have been proposed ('length' is in the PaceLinkRelated [2]. I prefer (content-)length, as size appears ambiguous. 4) Perhaps we could add a 'dimension' attribute for images? kidding. Lance [1] http://www.imc.org/atom-syntax/mail-archive/msg03805.html [2] http://www.intertwingly.net/wiki/pie/PaceLinkRelated On Wed, 05 Jan 2005 13:36:06 -0800, Tim Bray wrote: > > There are a couple of areas where we don't quite have feature parity > with RSS2.0, this tries to address that: > http://www.intertwingly.net/wiki/pie/PaceEnclosuresAndPix -Tim > > From owner-atom-syntax@mail.imc.org Wed Jan 5 17:37: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 RAA26845 for ; Wed, 5 Jan 2005 17:37: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 j05MSDWV022875; Wed, 5 Jan 2005 14:28: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 j05MSDpx022874; Wed, 5 Jan 2005 14:28: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 ([161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j05MSCZ5022556 for ; Wed, 5 Jan 2005 14:28:12 -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 j05MQSw0010379; Wed, 5 Jan 2005 22:26:43 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--44745953; protocol="application/pkcs7-signature" Message-Id: Cc: "'Atom WG'" From: Graham Subject: Re: Posted PaceEnclosuresAndPix Date: Wed, 5 Jan 2005 22:26:28 +0000 To: Tim Bray X-Mailer: Apple Mail (2.619) 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--44745953 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 5 Jan 2005, at 9:36 pm, Tim Bray wrote: > There are a couple of areas where we don't quite have feature parity > with RSS2.0, this tries to address that: > http://www.intertwingly.net/wiki/pie/PaceEnclosuresAndPix -Tim I can understand the enclosures one, but has the image tag in RSS ever served a useful purpose? Without any standard size they're very hard to incorporate into most layouts. Every usage of them I've seen has always looked very awkward because of this. A reliable way to locate favicons would actually be useful. (I'd like some explanation of why the two proposed elements are crowbarred into the link element, btw) Graham --Apple-Mail-4--44745953 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 9w0BCQUxDxcNMDUwMTA1MjIyNjI5WjAjBgkqhkiG9w0BCQQxFgQU6LEtGLxN5c1yKmczxqolsFFF /v4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAhtbrf7PIZvRwl54RFZt5eZUr oqSiaGefYt+kHhpmnY+33Z7UlxYWk5ThGr3usyfqKID7FVODyB0pXv/TvUAuZfR0nGeOsXhWpquv nrfnQ7Et/M3JgHlUAl1DylgyL4xgigB4z8jfDOdwbgTgmRn/Lftp3WBpL2wYb06unrY3By/FNDHu FViU7YRxyCAl/PLr5NZ+hF0b85TxshXlYFfYd7e5q+2e2V9YN5fwzsd/4sWSNLNuRssygKxMMORc dCwn7O1t/4urgFarPqInbR4opqVj+H2odF03X19+TuQnphMzVDr9lpsI4Maa2fKULYU4N2lAI6uc 6nQ0N7PhZ3U2rgAAAAAAAA== --Apple-Mail-4--44745953-- From owner-atom-syntax@mail.imc.org Wed Jan 5 18:00: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 SAA28150 for ; Wed, 5 Jan 2005 18:00: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 j05MqL5X040180; Wed, 5 Jan 2005 14:52: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 j05MqLNp040179; Wed, 5 Jan 2005 14:52:21 -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 j05MqK68040172 for ; Wed, 5 Jan 2005 14:52:20 -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 j05MqPdt000523 for ; Wed, 5 Jan 2005 15:52:25 -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 <0I9V007CZ8VD8M@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 05 Jan 2005 15:52:26 -0700 (MST) Received: from [192.168.1.40] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9V000H18VC7R@mail.sun.net> for atom-syntax@imc.org; Wed, 05 Jan 2005 15:52:25 -0700 (MST) Date: Wed, 05 Jan 2005 14:52:21 -0800 From: Tim Bray Subject: Re: Posted PaceEnclosuresAndPix In-reply-to: <96d7d77c0501051428125ae064@mail.gmail.com> To: Lance Lavandowska Cc: Atom WG Message-id: <758E5557-5F6C-11D9-A2C8-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <96d7d77c0501051428125ae064@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 5, 2005, at 2:28 PM, Lance Lavandowska wrote: > 1) There has been some controversy as to the "arbitrary" restriction > of one enclosure per item in RSS. Should we duplicate that > restriction? If so, why? Based on the discussion at http://www.reallysimplesyndication.com/2004/12/21#a221 and http://www.reallysimplesyndication.com/comments? u=reallySimpleSyndic&p=221&link=http%3A%2F%2Fwww.reallysimplesyndication .com%2F2004%2F12%2F21%23a221 I'm inclined to agree, don't see much of a downside for Atom. > 2) Why not have an 'image' link in an entry? I recall discussion of > using <content src="..."%gt; or somesuch for graphics, but has a > Flikr-like usecase been discussed? Using an 'image' link and regular > content seems appropriate. I'm adding these things because they're actually deployed and used. There are a lot of things we could we could ask "why not" about. > 3) On the 'size' attribute. 'size', 'length' and 'content-length' > have been proposed ('length' is in the PaceLinkRelated [2]. I prefer > (content-)length, as size appears ambiguous. Oops, right. -Tim From owner-atom-syntax@mail.imc.org Wed Jan 5 18:00: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 SAA28192 for ; Wed, 5 Jan 2005 18:00: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 j05MkbLr035308; Wed, 5 Jan 2005 14:46: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 j05Mkbkv035307; Wed, 5 Jan 2005 14:46:37 -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 j05MkbOA035193 for ; Wed, 5 Jan 2005 14:46: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 (rwcrmhc12) with SMTP id <2005010522463601400revbfe>; Wed, 5 Jan 2005 22:46:36 +0000 Date: Wed, 5 Jan 2005 15:46:35 -0700 Subject: Re: Posted PaceEnclosuresAndPix 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 If we're going to restrict how many enclosures and/or images an entry can have, we should build that kind of information into the @rel registry, and it might be good, if possible, to come up with some kind of policy or guideline for how to determine whether such a restriction will be applied to future @rel values. Given (what I suspect would be) the difficulty of coming up with such a policy, I'd prefer not to have any such restrictions. And if we do decide to have such restrictions for images and enclosures, then perhaps isn't the right way to point to these resources. BTW, is PaceLinkPurpose completely dead or is it still gasping for life while waiting for language to be written[1] that consensus can be built on? If the dream is not dead, then I don't think is the right place for images, and perhaps not for enclosures either, though I wouldn't argue strenuously against that. Antone [1] http://www.imc.org/atom-syntax/mail-archive/msg11631.html From owner-atom-syntax@mail.imc.org Wed Jan 5 18:12: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 SAA29294 for ; Wed, 5 Jan 2005 18:12: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 j05N4ehp053872; Wed, 5 Jan 2005 15:04: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 j05N4e3l053871; Wed, 5 Jan 2005 15:04:40 -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] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j05N4e57053359 for ; Wed, 5 Jan 2005 15:04:40 -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 <2005010523040701500ccitre>; Wed, 5 Jan 2005 23:04:07 +0000 Date: Wed, 5 Jan 2005 16:04:06 -0700 Subject: Re: Posted PaceEnclosuresAndPix 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: <196856E0-5F6E-11D9-8F93-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, January 5, 2005, at 03:26 PM, Graham wrote: > I can understand the enclosures one, but has the image tag in RSS ever > served a useful purpose? Without any standard size they're very hard > to incorporate into most layouts. Every usage of them I've seen has > always looked very awkward because of this. I've found it useful, and haven't thought it that difficult to deal with the odd sizes. If you're using an HTML widget to do your layout (or converting to HTML and embedding in a web page), all you have to do is specify a width attribute in your img tag (and set the width the same for each image) and the image will get scaled, automatically maintaining the correct aspect ratio. The heights won't all be the same, and if a particular souce image is smaller than the width you've chosen, you'll get some pixelation[1], but I've found the results to be entirely satisfactory in most cases. [1] If the XML specifies the image width, or if you check the dimensions of the images, you can often leave smaller images at their original size rather than scaling them up, depending on your layout. If, for example, you're floating images to one side, it's much more important to scale down large images than to scale up small ones to get your layout to look decent. So yes, to some of us at least, it is useful. Antone From owner-atom-syntax@mail.imc.org Wed Jan 5 18:37: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 SAA04353 for ; Wed, 5 Jan 2005 18:37: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 j05NSNh1065265; Wed, 5 Jan 2005 15:28: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 j05N3YD8053320; Wed, 5 Jan 2005 15:03:34 -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 j05N3T43053130 for ; Wed, 5 Jan 2005 15:03:30 -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 j05N3Ydt008790 for ; Wed, 5 Jan 2005 16:03:34 -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 <0I9V007NG9DX8M@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 05 Jan 2005 16:03:34 -0700 (MST) Received: from [192.168.1.40] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9V000L49DU7R@mail.sun.net> for atom-syntax@imc.org; Wed, 05 Jan 2005 16:03:31 -0700 (MST) Date: Wed, 05 Jan 2005 15:03:21 -0800 From: Tim Bray Subject: Re: Posted PaceEnclosuresAndPix In-reply-to: To: Graham Cc: "'Atom WG'" 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: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 5, 2005, at 2:26 PM, Graham wrote: > I can understand the enclosures one, but has the image tag in RSS ever > served a useful purpose? Without any standard size they're very hard > to incorporate into most layouts. Every usage of them I've seen has > always looked very awkward because of this. A reliable way to locate > favicons would actually be useful. I think Graham's right. In fact, I just looked around and I can't find any software that still actually uses them... unless someone shouts "keep it" I'm inclined to lose it. -Tim From owner-atom-syntax@mail.imc.org Wed Jan 5 18:37: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 SAA04371 for ; Wed, 5 Jan 2005 18:37: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 j05NPxeP065091; Wed, 5 Jan 2005 15: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 j05NPx4S065090; Wed, 5 Jan 2005 15:25:59 -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 j05NPwxV065080 for ; Wed, 5 Jan 2005 15:25:58 -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 j05NQ3dt025188 for ; Wed, 5 Jan 2005 16:26:03 -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 <0I9V0074KAFEHO@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 05 Jan 2005 16:26:03 -0700 (MST) Received: from [192.168.1.40] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9V000T3AFE7R@mail.sun.net> for atom-syntax@imc.org; Wed, 05 Jan 2005 16:26:02 -0700 (MST) Date: Wed, 05 Jan 2005 15:25:58 -0800 From: Tim Bray Subject: Re: Posted PaceEnclosuresAndPix In-reply-to: <196856E0-5F6E-11D9-8F93-003065EA6144@geckotribe.com> To: Antone Roundy Cc: atom-syntax@imc.org Message-id: <27A8E40D-5F71-11D9-A2C8-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: <196856E0-5F6E-11D9-8F93-003065EA6144@geckotribe.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 5, 2005, at 3:04 PM, Antone Roundy wrote: > > On Wednesday, January 5, 2005, at 03:26 PM, Graham wrote: >> I can understand the enclosures one, but has the image tag in RSS >> ever served a useful purpose? Without any standard size they're very >> hard to incorporate into most layouts. Every usage of them I've seen >> has always looked very awkward because of this. > > I've found it useful Where? I haven't been able to find anywhere that's actually using them. Bloglines used to, but no longer. -Tim From owner-atom-syntax@mail.imc.org Wed Jan 5 19:04: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 TAA06218 for ; Wed, 5 Jan 2005 19:04: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 j05Nsk7u075578; Wed, 5 Jan 2005 15:54: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 j05NskGW075575; Wed, 5 Jan 2005 15:54: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 j05NskuX075501 for ; Wed, 5 Jan 2005 15:54:46 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12ld24r.cable.mindspring.com ([69.86.136.155] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CmKz9-0008Ld-QF; Wed, 05 Jan 2005 23:54:39 +0000 Message-ID: <41DC7E3F.40409@franklinmint.fm> Date: Wed, 05 Jan 2005 15:54:39 -0800 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: Antone Roundy , atom-syntax@imc.org Subject: Re: Posted PaceEnclosuresAndPix References: <196856E0-5F6E-11D9-8F93-003065EA6144@geckotribe.com> <27A8E40D-5F71-11D9-A2C8-000A95A51C9E@sun.com> In-Reply-To: <27A8E40D-5F71-11D9-A2C8-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 Jan 5, 2005, at 3:04 PM, Antone Roundy wrote: > >> >> On Wednesday, January 5, 2005, at 03:26 PM, Graham wrote: >> >>> I can understand the enclosures one, but has the image tag in RSS >>> ever served a useful purpose? Without any standard size they're very >>> hard to incorporate into most layouts. Every usage of them I've seen >>> has always looked very awkward because of this. >> >> >> I've found it useful > > > Where? I haven't been able to find anywhere that's actually using > them. Bloglines used to, but no longer. -Tim > Bloglines still uses it in some places: http://bloglines.com/preview?siteid=2213 Hmm. I don't know of any GUI clients that show them (web stuff like Magpie and Amphetadesk can be made to do it), but what's a LiveJournal feed without a photo? http://www.livejournal.com/~brad/data/rss http://bloglines.com/preview?siteid=530866 Robert Sayre From owner-atom-syntax@mail.imc.org Wed Jan 5 19:07: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 TAA06451 for ; Wed, 5 Jan 2005 19:07: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 j05NxeHP080921; Wed, 5 Jan 2005 15: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 j05Nxe72080920; Wed, 5 Jan 2005 15:59:40 -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 j05NxeKv080811 for ; Wed, 5 Jan 2005 15:59:40 -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 <2005010523593701600popa5e>; Wed, 5 Jan 2005 23:59:37 +0000 Date: Wed, 5 Jan 2005 16:59:35 -0700 Subject: Re: Posted PaceEnclosuresAndPix 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: <27A8E40D-5F71-11D9-A2C8-000A95A51C9E@sun.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 Wednesday, January 5, 2005, at 04:25 PM, Tim Bray wrote: > On Jan 5, 2005, at 3:04 PM, Antone Roundy wrote: >> On Wednesday, January 5, 2005, at 03:26 PM, Graham wrote: >>> I can understand the enclosures one, but has the image tag in RSS >>> ever served a useful purpose? Without any standard size they're very >>> hard to incorporate into most layouts. Every usage of them I've seen >>> has always looked very awkward because of this. >> >> I've found it useful > > Where? I haven't been able to find anywhere that's actually using > them. Bloglines used to, but no longer. -Tim > A quick look through my cache files turns it up in five feeds (though only for a channel image, not item images). The feeds come from WashingtonPost.com, Slashdot, CNET News, Wired News, and yes, Ongoing. A quick grep of the cache files from my Jawfish service (which converts RSS to JavaScript for display on sites that can't do it some other way) turns up 611 feeds containing an element, all of which appear to use it only for channel images. Okay, I guess it's been a while since I knew where to find a feed that used in s. From owner-atom-syntax@mail.imc.org Wed Jan 5 19:09: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 TAA06591 for ; Wed, 5 Jan 2005 19:09: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 j0603GUr084469; Wed, 5 Jan 2005 16: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 j0603GoO084468; Wed, 5 Jan 2005 16:03:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from tomts22-srv.bellnexxia.net (tomts22.bellnexxia.net [209.226.175.184]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0603FWs084249 for ; Wed, 5 Jan 2005 16:03:16 -0800 (PST) (envelope-from kier@sdf1.net) Received: from [192.168.1.102] ([65.95.95.125]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050106000304.QQOW1919.tomts22-srv.bellnexxia.net@[192.168.1.102]>; Wed, 5 Jan 2005 19:03:04 -0500 In-Reply-To: <758E5557-5F6C-11D9-A2C8-000A95A51C9E@sun.com> References: <96d7d77c0501051428125ae064@mail.gmail.com> <758E5557-5F6C-11D9-A2C8-000A95A51C9E@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4--38953384" Message-Id: <54CD5E58-5F76-11D9-A316-000D93C9CE82@sdf1.net> Cc: atom-syntax@imc.org From: Ray Slakinski Subject: Re: Posted PaceEnclosuresAndPix Date: Wed, 5 Jan 2005 19:03:01 -0500 To: Tim Bray Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-4--38953384 Content-Type: multipart/alternative; boundary=Apple-Mail-3--38953406 --Apple-Mail-3--38953406 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On 5-Jan-05, at 5:52 PM, Tim Bray wrote: >> 1) There has been some controversy as to the "arbitrary" restriction >> of one enclosure per item in RSS. Should we duplicate that >> restriction? If so, why? > > Based on the discussion at > http://www.reallysimplesyndication.com/2004/12/21#a221 and > http://www.reallysimplesyndication.com/comments? > u=reallySimpleSyndic&p=221&link=http%3A%2F%2Fwww.reallysimplesyndicatio > n.com%2F2004%2F12%2F21%23a221 I'm inclined to agree, don't see much of > a downside for Atom. I would like to see Atom support multiple enclosures because I feel the 1 enclosure per item/entry is quite limiting when sending out separate files of related information. I like to use the email analogy when talking about enclosures. In the current implementation of RSS, you would be restricted to only adding one attachment per email. But say you have 4 baby photos that were taken during his/her first birthday. Now I have to send out 4 emails to the same person, the first one with a description and a photo, and 3 other emails with each other photo. In addition to being cumbersome, there is no good way to show that the photos all go together. With multiple enclosures I can group all that related information together. Dave does bring up some good points about duplicating a lot of extra information inside the enclosure tag, but I feel that most data can be either inherited from the encasing item tag or is encased in the file's own metadata. An ID tag per file is all that would be needed to keep the files separate and distinct. Because they see value in several files per item, Yahoo is now trying to extend RSS to support multiple enclosures. Should we not solve this need prior to having to tack on extra layers later? [-----] Ray Slakinski Fingerprint: C8AD 4847 2DA8 3469 079D 13F9 135D F0CF 1CFC FD03 Blog: http://ddll.sdf1.net The verdict of a jury is the a priori opinion of that juror who smokes the worst cigars. -- H. L. Mencken --Apple-Mail-3--38953406 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit On 5-Jan-05, at 5:52 PM, Tim Bray wrote: 1) There has been some controversy as to the "arbitrary" restriction of one enclosure per item in RSS. Should we duplicate that restriction? If so, why? Based on the discussion at http://www.reallysimplesyndication.com/2004/12/21#a221 and http://www.reallysimplesyndication.com/comments?u=reallySimpleSyndic&p=221&link=http%3A%2F%2Fwww.reallysimplesyndication.com%2F2004%2F12%2F21%23a221 I'm inclined to agree, don't see much of a downside for Atom. Lucida Grande0000,0707,8888I would like to see Atom support multiple enclosures because I feel the 1 enclosure per item/entry is quite limiting when sending out separate files of related information. I like to use the email analogy when talking about enclosures. In the current implementation of RSS, you would be restricted to only adding one attachment per email. But say you have 4 baby photos that were taken during his/her first birthday. Now I have to send out 4 emails to the same person, the first one with a description and a photo, and 3 other emails with each other photo. In addition to being cumbersome, there is no good way to show that the photos all go together. With multiple enclosures I can group all that related information together. Dave does bring up some good points about duplicating a lot of extra information inside the enclosure tag, but I feel that most data can be either inherited from the encasing item tag or is encased in the file's own metadata. An ID tag per file is all that would be needed to keep the files separate and distinct. Because they see value in several files per item, Yahoo is now trying to extend RSS to support multiple enclosures. Should we not solve this need prior to having to tack on extra layers later? [-----] Ray Slakinski Fingerprint: C8AD 4847 2DA8 3469 079D 13F9 135D F0CF 1CFC FD03 Blog: http://ddll.sdf1.net The verdict of a jury is the a priori opinion of that juror who smokes the worst cigars. -- H. L. Mencken --Apple-Mail-3--38953406-- --Apple-Mail-4--38953384 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkHcgDYACgkQE13wzxz8/QN1zgCdG932kiWtee56kY2cw4b00BxZ d30An2+DrLEJc+W6NaYPAe8EDE8l/tEZ =sSRc -----END PGP SIGNATURE----- --Apple-Mail-4--38953384-- From owner-atom-syntax@mail.imc.org Wed Jan 5 19:34: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 TAA07898 for ; Wed, 5 Jan 2005 19:34: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 j060P0bM005601; Wed, 5 Jan 2005 16:25: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 j060P036005598; Wed, 5 Jan 2005 16:25: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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j060OxTq005435 for ; Wed, 5 Jan 2005 16:24:59 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so540527rnz for ; Wed, 05 Jan 2005 16:25:01 -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=MS4QbAPa1agBNMnMUEZ/7PbmHZyss3yxwOIEPJhp2KD8PzOdUT8bP5qeon+yrNxEgDfNSgCNRQJTpTyOq07HommIeilTojaqNnbbakin0DNJ30nDRtw1JlbhTE3lq0eIm7796MYxdVH4fSbfNtl7Ui2YqMKSwTIjaI3n5+aKgLs= Received: by 10.38.8.61 with SMTP id 61mr450765rnh; Wed, 05 Jan 2005 16:25:01 -0800 (PST) Received: by 10.38.179.58 with HTTP; Wed, 5 Jan 2005 16:25:01 -0800 (PST) Message-ID: <1f2ed5cd050105162514f7773f@mail.gmail.com> Date: Thu, 6 Jan 2005 01:25:01 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: Posted PaceEnclosuresAndPix 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 Wed, 05 Jan 2005 13:36:06 -0800, Tim Bray wrote: > > There are a couple of areas where we don't quite have feature parity > with RSS2.0, this tries to address that: > http://www.intertwingly.net/wiki/pie/PaceEnclosuresAndPix -Tim I could live with this Pace, feature parity and ease of migration being good justification for the approach. But - 1. If the media object is the primary content of the entry (which seems to be the main use case for RSS 2.0's ), shouldn't it be delivered using some form of the element? 2. Without multiple rel="enclosure", how does support and differentiate between media objects that are essentially the same resource but different formats, where the difference may not (easily) be expressed using mime types? Example: "Tim's award acceptance speech" (pretty good quality: mp3, 16bit, stereo, 44.1kHz 128Kbit compression) "Tim's award acceptance speech" (for saddos like danny with dialups: mp3, 12bit, mono, 11.025kHz 56Kbit compression) 3. I don't think this Pace is the right place for listing what should go in the registry - separation of concerns and all that 4. What do we call an inline (i.e. base64 encoded content) media object - an attachment? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Jan 5 19:43: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 TAA08492 for ; Wed, 5 Jan 2005 19: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 j060avKB021325; Wed, 5 Jan 2005 16:37: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 j060atv5021317; Wed, 5 Jan 2005 16:36:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [69.20.61.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j060ah26021188 for ; Wed, 5 Jan 2005 16:36:44 -0800 (PST) (envelope-from brent@ranchero.com) Received: from [192.168.0.3] (c-67-171-27-118.client.comcast.net [67.171.27.118]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.10) with ESMTP id j060afS3032755 for ; Wed, 5 Jan 2005 19:36:41 -0500 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <41DC7E3F.40409@franklinmint.fm> References: <196856E0-5F6E-11D9-8F93-003065EA6144@geckotribe.com> <27A8E40D-5F71-11D9-A2C8-000A95A51C9E@sun.com> <41DC7E3F.40409@franklinmint.fm> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Brent Simmons Subject: Re: Posted PaceEnclosuresAndPix Date: Wed, 5 Jan 2005 16:36:08 -0800 To: atom-syntax@imc.org X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 5, 2005, at 3:54 PM, Robert Sayre wrote: > Tim Bray wrote: >> On Jan 5, 2005, at 3:04 PM, Antone Roundy wrote: >>> >>> On Wednesday, January 5, 2005, at 03:26 PM, Graham wrote: >>> >>>> I can understand the enclosures one, but has the image tag in RSS >>>> ever served a useful purpose? Without any standard size they're >>>> very hard to incorporate into most layouts. Every usage of them >>>> I've seen has always looked very awkward because of this. >>> >>> >>> I've found it useful >> Where? I haven't been able to find anywhere that's actually using >> them. Bloglines used to, but no longer. -Tim > > Bloglines still uses it in some places: > http://bloglines.com/preview?siteid=2213 > > Hmm. I don't know of any GUI clients that show them (web stuff like > Magpie and Amphetadesk can be made to do it), but what's a LiveJournal > feed without a photo? > > http://www.livejournal.com/~brad/data/rss > http://bloglines.com/preview?siteid=530866 Some GUI apps do display feed-level images. Here's a screenshot: http://ranchero.com/images/bradsLife.png But, since they are of varying sizes, they tend to be tucked away in the UI rather than displayed prominently. Were there a standard size, then a GUI app could do something like how iTunes displays album cover art. -Brent From owner-atom-syntax@mail.imc.org Wed Jan 5 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 TAA08963 for ; Wed, 5 Jan 2005 19:53: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 j060dnIq021918; Wed, 5 Jan 2005 16:39: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 j060dnsO021917; Wed, 5 Jan 2005 16:39: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 j060dmTL021911 for ; Wed, 5 Jan 2005 16:39:48 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12ld24r.cable.mindspring.com ([69.86.136.155] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CmLgl-0000Gf-Tj; Thu, 06 Jan 2005 00:39:44 +0000 Message-ID: <41DC88CE.3000706@franklinmint.fm> Date: Wed, 05 Jan 2005 16:39:42 -0800 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: Danny Ayers CC: Tim Bray , Atom WG Subject: Re: Posted PaceEnclosuresAndPix References: <1f2ed5cd050105162514f7773f@mail.gmail.com> In-Reply-To: <1f2ed5cd050105162514f7773f@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 Danny Ayers wrote: > > 1. If the media object is the primary content of the entry (which > seems to be the main use case for RSS 2.0's ), shouldn't it > be delivered using some form of the element? Stick it in the content pane, don't bother preloading it. If you want the equivalent of RSS2, you can still do that with and > > 2. Without multiple rel="enclosure", how does support and > differentiate between media objects that are essentially the same > resource but different formats, where the difference may not (easily) > be expressed using mime types? Example: > > "Tim's award acceptance speech" (pretty good quality: mp3, 16bit, > stereo, 44.1kHz 128Kbit compression) > > "Tim's award acceptance speech" (for saddos like danny with dialups: > mp3, 12bit, mono, 11.025kHz 56Kbit compression) > The mime type should have parameters for that stuff, shouldn't it? Doesn't seem like our problem. > 3. I don't think this Pace is the right place for listing what should > go in the registry - separation of concerns and all that > Doesn't matter. > 4. What do we call an inline (i.e. base64 encoded content) media > object - an attachment? We call it the "content", which comes from the element, whose definition says it conveys the "content" :) Robert Sayre From owner-atom-syntax@mail.imc.org Wed Jan 5 20:13: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 UAA10061 for ; Wed, 5 Jan 2005 20:13: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 j0614gfS023899; Wed, 5 Jan 2005 17:04: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 j0614gZJ023898; Wed, 5 Jan 2005 17:04:42 -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 j0614fZN023892 for ; Wed, 5 Jan 2005 17:04: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 j0614iVu018284 for ; Wed, 5 Jan 2005 18:04:45 -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 <0I9V008EYEZVE9@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 05 Jan 2005 18:04:44 -0700 (MST) Received: from [192.168.1.40] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9V006UKEZV44@mail.sun.net> for atom-syntax@imc.org; Wed, 05 Jan 2005 18:04:43 -0700 (MST) Date: Wed, 05 Jan 2005 17:04:39 -0800 From: Tim Bray Subject: Re: Posted PaceEnclosuresAndPix In-reply-to: <1f2ed5cd050105162514f7773f@mail.gmail.com> To: Danny Ayers Cc: Atom WG 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: <1f2ed5cd050105162514f7773f@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 5, 2005, at 4:25 PM, Danny Ayers wrote: > 1. If the media object is the primary content of the entry (which > seems to be the main use case for RSS 2.0's ), shouldn't it > be delivered using some form of the element? I used to think that, but we observe in the RSS2 world that there's a well-accepted use case for something that's specially designated for different handling. Why fight it? > 2. Without multiple rel="enclosure", how does support and > differentiate between media objects that are essentially the same > resource but different formats, where the difference may not (easily) > be expressed using mime types? Example: I'm pretty well convinced that multiples can't hurt. > 3. I don't think this Pace is the right place for listing what should > go in the registry - separation of concerns and all that That's because it's done as a delta to FieldingLinks, the new languages goes in a couple of places in that section so I just preserved it. > 4. What do we call an inline (i.e. base64 encoded content) media > object - an attachment? Nope, that's just -Tim From owner-atom-syntax@mail.imc.org Wed Jan 5 20:13: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 UAA10079 for ; Wed, 5 Jan 2005 20:13: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 j0616xg2024074; Wed, 5 Jan 2005 17:06: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 j0616xO4024073; Wed, 5 Jan 2005 17:06:59 -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 j0616w64024067 for ; Wed, 5 Jan 2005 17:06:58 -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 j06174dt000399 for ; Wed, 5 Jan 2005 18:07:04 -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 <0I9V008E9F3RHI@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 05 Jan 2005 18:07:04 -0700 (MST) Received: from [192.168.1.40] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9V0070AF3ROK@mail.sun.net> for atom-syntax@imc.org; Wed, 05 Jan 2005 18:07:03 -0700 (MST) Date: Wed, 05 Jan 2005 17:06:59 -0800 From: Tim Bray Subject: Re: Posted PaceEnclosuresAndPix In-reply-to: To: Brent Simmons Cc: atom-syntax@imc.org Message-id: <444AE6C7-5F7F-11D9-A2C8-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: <196856E0-5F6E-11D9-8F93-003065EA6144@geckotribe.com> <27A8E40D-5F71-11D9-A2C8-000A95A51C9E@sun.com> <41DC7E3F.40409@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 5, 2005, at 4:36 PM, Brent Simmons wrote: > Some GUI apps do display feed-level images. Here's a screenshot: > http://ranchero.com/images/bradsLife.png > > But, since they are of varying sizes, they tend to be tucked away in > the UI rather than displayed prominently. Were there a standard size, > then a GUI app could do something like how iTunes displays album cover > art. Hmm... sounds like it does no harm. Think we could get away something like "The aspect ratio of the image SHOULD be 3:2 and software MAY resize it as desired."? -Tim From owner-atom-syntax@mail.imc.org Wed Jan 5 20:22: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 UAA10794 for ; Wed, 5 Jan 2005 20:22: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 j061Ga8I024898; Wed, 5 Jan 2005 17: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 j061Ga6l024897; Wed, 5 Jan 2005 17:16:36 -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 j061GaGA024891 for ; Wed, 5 Jan 2005 17:16:36 -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 j061GfVu025571 for ; Wed, 5 Jan 2005 18:16: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 <0I9V008AFFJRHI@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 05 Jan 2005 18:16:39 -0700 (MST) Received: from [192.168.1.40] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9V006W5FJQ44@mail.sun.net> for atom-syntax@imc.org; Wed, 05 Jan 2005 18:16:39 -0700 (MST) Date: Wed, 05 Jan 2005 17:16:34 -0800 From: Tim Bray Subject: Work Queue Rotation #14 To: Atom WG Message-id: <9B27BC04-5F80-11D9-A2C8-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 The current active-issues list is at http://www.intertwingly.net/wiki/pie/AtomPubIssuesList As always, we may have mis-read the sentiment of the group, push back as appropriate. PaceCategoryRevised - Bob Wyman argued for an alternative (http://www.imc.org/atom-syntax/mail-archive/msg11669.html) but eventually abandoned this as quixotic. Graham Parks raised objections to the optionality of some attributes (http://www.imc.org/atom-syntax/mail-archive/msg11780.html) but got a pretty good answer (http://www.imc.org/atom-syntax/mail-archive/msg11781.html). And there were a bunch of +1's. So I think we've crossed the rough-consensus boundary and can say "accepted". PaceCollectionIdiom - Got no comments, but provoked Rob Sayre's comprehensive DAV-flavored proposal. I don't think we're ready either to accept or reject. PaceIntrospection - I think consensus emerged on the protocol list, on the proposal with some modifications; sorting it out requires a bit of tracing through the threads, but I think two Gregorio messages are crucial: http://www.imc.org/atom-protocol/mail-archive/msg00252.html and http://www.imc.org/atom-protocol/mail-archive/msg00255.html - since Rob and Joe were arguing over the details here, and were converging, and are the editors of the Protocol draft, I think we can mark this accepted and task them with getting the consensus recorded properly. PaceProblemStatements - I saw a few +1's and no dissent. Accepted. PaceTwoProtocolDocs - Lots of +1's, with an open issue from Dave Johnson as to whether Commenting features if any go in Basic or Administrative (see http://www.imc.org/atom-protocol/mail-archive/msg00358.html, with backup from Lance Lavandowska). Accepted. -Tim From owner-atom-syntax@mail.imc.org Wed Jan 5 20:29: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 UAA11744 for ; Wed, 5 Jan 2005 20: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 j061MhZk030495; Wed, 5 Jan 2005 17:22: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 j061Mhjo030494; Wed, 5 Jan 2005 17:22:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [69.20.61.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j061Mgwt030488 for ; Wed, 5 Jan 2005 17:22:42 -0800 (PST) (envelope-from brent@ranchero.com) Received: from [192.168.0.3] (c-67-171-27-118.client.comcast.net [67.171.27.118]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.10) with ESMTP id j061MjIv005919 for ; Wed, 5 Jan 2005 20:22:45 -0500 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <444AE6C7-5F7F-11D9-A2C8-000A95A51C9E@sun.com> References: <196856E0-5F6E-11D9-8F93-003065EA6144@geckotribe.com> <27A8E40D-5F71-11D9-A2C8-000A95A51C9E@sun.com> <41DC7E3F.40409@franklinmint.fm> <444AE6C7-5F7F-11D9-A2C8-000A95A51C9E@sun.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6D6DDDF0-5F81-11D9-93D7-000A95CA7396@ranchero.com> Content-Transfer-Encoding: 7bit From: Brent Simmons Subject: Re: Posted PaceEnclosuresAndPix Date: Wed, 5 Jan 2005 17:22:27 -0800 To: atom-syntax@imc.org X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 5, 2005, at 5:06 PM, Tim Bray wrote: > On Jan 5, 2005, at 4:36 PM, Brent Simmons wrote: > >> Some GUI apps do display feed-level images. Here's a screenshot: >> http://ranchero.com/images/bradsLife.png >> >> But, since they are of varying sizes, they tend to be tucked away in >> the UI rather than displayed prominently. Were there a standard size, >> then a GUI app could do something like how iTunes displays album >> cover art. > > Hmm... sounds like it does no harm. Think we could get away something > like "The aspect ratio of the image SHOULD be 3:2 and software MAY > resize it as desired."? -Tim For me that would work quite well. I'd like very much to make feed images more prominent, for UI reasons -- some of the graphics I've seen are interesting, and, more importantly, they provide a visual clue to the source of what you're reading. -Brent From owner-atom-syntax@mail.imc.org Wed Jan 5 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 UAA12407 for ; Wed, 5 Jan 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 j061Q3h1030954; Wed, 5 Jan 2005 17:26: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 j061Q3CZ030951; Wed, 5 Jan 2005 17:26:03 -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 j061Q1b1030930 for ; Wed, 5 Jan 2005 17:26:01 -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 j061Q7dt012184 for ; Wed, 5 Jan 2005 18:26:07 -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 <0I9V008K0FZIE9@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 05 Jan 2005 18:26:07 -0700 (MST) Received: from [192.168.1.40] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9V0074NFZIOK@mail.sun.net> for atom-syntax@imc.org; Wed, 05 Jan 2005 18:26:06 -0700 (MST) Date: Wed, 05 Jan 2005 17:26:02 -0800 From: Tim Bray Subject: The Atom Format end-game To: Atom WG 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 represents the result of discussions between Paul and myself, and is our position as co-chairs of the Atompub WG. Beginning with the conclusion: 1. We *must* finalize the format. Our deadline is drawing near and we need to focus on the publishing protocol. 2. We are close to RSS2 feature-compatibility, we either adopt image & enclosure or make a conscious decision not to. 3. Based on the detailed analysis below from the mailing list, there is rough consensus that the only remaining point we MUST settle in the format is extensibility. Likely MustIgnore can gain consensus support via PaceExtendingAtom, perhaps with some fine-tuning. Which leaves MustUnderstand. It is possible that PaceMustUnderstandElement might get in if we either convince Joe Gregorio or decide to declare rough consensus over his objections. Or maybe not. Co-chairs can live with either. Basis for this analysis: Hoffman: http://www.imc.org/atom-syntax/mail-archive/msg11315.html - What's the Minimum Progress Required to Declare Victory? Here's what was offered in response: [CO-CHAIR COMMENTS LIKE THIS]. Sayre: http://www.imc.org/atom-syntax/mail-archive/msg11327.html - PaceFieldingLinks [ACCEPTED] - PaceUpdatedDefinition [ACCEPTED] - Extensibility Parks: http://www.imc.org/atom-syntax/mail-archive/msg11323.html - atom:updated is currently required. I think this will lead to it being polluted with general "Last Modified" dates, severely limiting its usefulness. Seeing as it is not possible to make an element optional after v1.0, but it is possible to do the reverse, this one seems urgent. [REQUIRES A PACE, GIVE IT A TRY, WE'RE PESSIMISTIC] - The discredited atom:id canonicalization nonsense still stands [DITTO] - The use of terminology is very poor. For example, several elements define whether they can "change" or not. How can a server ever change something after it has been transmitted? What we mean to say is whether or not all instances of an entry should have the same value. [SAYRE ACCEPTED THIS AS AN EDITORIAL ISSUE] - ditto "permanent, universally unique identifier" [DON'T UNDERSTAND] - No discussion on how xml:space applies to content types [DO A PACE, MIGHT FLY] - type="TEXT" does not define handling of line breaks [DITTO] - No discussion on whether whitespace or parameters are allowed in @type [DITTO] - Section 6 "Managing Feed State" could be a key differentiator between Atom and RSS if it were written rather than dropped [DO A PACE, BUT WE'RE PESSIMISTIC] Roundy: http://www.imc.org/atom-syntax/mail-archive/msg11318.html - Links: I'd love to see this nailed down a little better, but my hope of reaching consensus is fading, and I don't know how much more energy I'll feel inclined to contribute to the effort. If we're going to punt on making this really good, but there are any minor tweaks that we CAN agree on, let's at least do those. [AGREE WITH PESSIMISM] - PaceHeadInEntry: Is there any reason not to put this in? (Note: I think it could use an example of an aggregated feed--the only example it has now is Atom over XMPP.) [ACCEPTED] - Categories: Sometimes useful. Never problematic, as far as I can tell. Shouldn't be too hard to nail down the specifics. Let's put it in. [PaceCategoryRevised ACCEPTED] - Enclosures/Images (both "favicons" and other feed- or entry-related images): Although one might use HTML in the content to point to some of these, for CaRP (which displays newsfeeds on webpages), I find it extremely useful to have these in a separate element--it gives the user much greater flexibility in formatting the output. Of course, if the publisher wants an image to be displayed in a particular way in relation to the rest of the content, then pointing to it from within the content is necessary, but if they simply want to specify an image (or whatever) to have displayed alongside the content in some way or another, a separate element is preferable. [PaceEnclosuresAndPix ADDRESSES THIS] - Explicit entry deletion: Another "why not put it in". Yes, once you've published something, it's out there, and you can't expunge it completely, but Arve's use-case[1] for deletion shows that there would be a real benefit to having a deletion mechanism (assuming it would get implemented, which I expect it would). This should be easy enough to hammer out specifics for[2]. Let's do it. [PROTOCOL, NOT FORMAT] - General Extensibility: I see no reason to rush to 1.0 without nailing this down better. On the other hand, I personally don't care much about the specifics, so I also see no reason to wrangle over them for a long time, if that's what would have to happen to get it done. Morin: http://www.imc.org/atom-syntax/mail-archive/msg11302.html - Include schemas! [WE AGREE, BUT WE THINK WE'LL GET THEM SOON AS WE ASK, LOTS OF PEOPLE SEEM HAPPY TO VOLUNTEER] Gregorio: http://www.imc.org/atom-syntax/mail-archive/msg11287.html - Any mention of extensibility in the format spec. - A feed level 'image' element, ala RSS 2.0 which, "Specifies a GIF, JPEG or PNG image that can be displayed with the channel." [PaceEnclosuresAndPix ADDRESSES THIS] From owner-atom-syntax@mail.imc.org Wed Jan 5 21:34: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 VAA15891 for ; Wed, 5 Jan 2005 21:34: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 j062GKKX034779; Wed, 5 Jan 2005 18:16: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 j062GKDN034778; Wed, 5 Jan 2005 18:16:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from tomts13-srv.bellnexxia.net (tomts13-srv.bellnexxia.net [209.226.175.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j062GJT2034770 for ; Wed, 5 Jan 2005 18:16:19 -0800 (PST) (envelope-from kier@sdf1.net) Received: from [192.168.1.102] ([65.95.95.125]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050106021616.BAPW1899.tomts13-srv.bellnexxia.net@[192.168.1.102]>; Wed, 5 Jan 2005 21:16:16 -0500 In-Reply-To: References: <1f2ed5cd050105162514f7773f@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom WG From: Ray Slakinski Subject: Re: Posted PaceEnclosuresAndPix Date: Wed, 5 Jan 2005 21:16:13 -0500 To: Tim Bray X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5-Jan-05, at 8:04 PM, Tim Bray wrote: > I'm pretty well convinced that multiples can't hurt. Sorry I was confused by your first post then. I'm very pleased that its more than a remote possibility to have this in Atom. I was wondering though about being able to identify one attachment from another. I suggested an ID before, and I think the ID could work well to solve some of the logistical issues with multiple enclosures. For Example: The ID element would be an optional just like content-size would be. [-----] Ray Slakinski Fingerprint: C8AD 4847 2DA8 3469 079D 13F9 135D F0CF 1CFC FD03 Blog: http://ddll.sdf1.net A person is just about as big as the things that make them angry. -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkHcn24ACgkQE13wzxz8/QOedwCeKFPUP0xS0blxJ9aKreIWGQ/H VaIAnRc91BwyMs9ud96m/b3S4QLGUc1w =IVoa -----END PGP SIGNATURE----- From owner-atom-syntax@mail.imc.org Thu Jan 6 02:01: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 CAA01758 for ; Thu, 6 Jan 2005 02:01: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 j066mG8K053584; Wed, 5 Jan 2005 22:48: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 j066mGfl053583; Wed, 5 Jan 2005 22:48:16 -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 j066mEb8053557 for ; Wed, 5 Jan 2005 22:48:16 -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 1CmRRM-0003zD-U7; Thu, 06 Jan 2005 06:48:13 +0000 Message-ID: <41DCDF32.7060001@franklinmint.fm> Date: Thu, 06 Jan 2005 01:48: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 WG Subject: Re: The Atom Format end-game 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: > 3. Based on the detailed analysis below from the mailing list, there > is rough consensus that the only remaining point we MUST settle in the > format is extensibility. Likely MustIgnore can gain consensus > support via PaceExtendingAtom, perhaps with some fine-tuning. Agree. > Which leaves MustUnderstand. It is possible that > PaceMustUnderstandElement might get in if we either convince Joe > Gregorio or decide to declare rough consensus over his objections. Or > maybe not. Co-chairs can live with either. I've heard convincing use cases for mU, but nothing that suggests we're adding anything that a SOAP header wouldn't take care of. If someone needs mU, why wouldn't they just send a feed or entry in a SOAP envelope, and make use of all that existing mU infrastructure? Also, when mU headers are added in HTTP 2.0, we get them for free ;) Put another way, seems like protocol, not format. > Parks: http://www.imc.org/atom-syntax/mail-archive/msg11323.html > - The use of terminology is very poor. For example, several elements > define whether they can "change" or not. How can a server ever change > something after it has been transmitted? What we mean to say is > whether or not all instances of an entry should have the same value. > [SAYRE ACCEPTED THIS AS AN EDITORIAL ISSUE] I had forgotten about this one, but Graham is correct that the spec needs to be looked over for handwaving and insular atomisms. > Roundy: http://www.imc.org/atom-syntax/mail-archive/msg11318.html > - Explicit entry deletion: Another "why not put it in". Yes, once > you've published something, it's out there, and you can't expunge it > completely, but Arve's use-case[1] for deletion shows that there would > be a real benefit to having a deletion mechanism (assuming it would > get implemented, which I expect it would). This should be easy enough > to hammer out specifics for[2]. Let's do it. [PROTOCOL, NOT FORMAT] The Atom-over-XMPP draft[0] and its WebDAV doppelganger[1] already report these events. Maybe those specs should define syntax to report executed HTTP events and re-use them in all three protocols (?). Robert Sayre [0] http://ietfreport.isoc.org/idref/draft-saintandre-atompub-notify/ [1] http://ietfreport.isoc.org/idref/draft-hildebrand-webdav-notify/ From owner-atom-syntax@mail.imc.org Thu Jan 6 08:29: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 IAA06634 for ; Thu, 6 Jan 2005 08: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 j06D494V027959; Thu, 6 Jan 2005 05:04: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 j06D49A9027958; Thu, 6 Jan 2005 05:04: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.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j06D48DU027883 for ; Thu, 6 Jan 2005 05:04:08 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so560765rnz for ; Thu, 06 Jan 2005 05:04:05 -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=e+DKjNCuHE1p1R+kMELWTjjW01+40v/FikXg3vdzGS5Pqo8R9ebfpvJ3Pikba2OAhxnow9wijLxDDSXJ417CJDnKQ2zS6iBtx0Et0a18nxHyL42fupPvPH8+j4V56NLNWbdNS7ba/vhEnOPItvLcQAhsfzxfqLhUCrdy9IirOoY= Received: by 10.38.8.13 with SMTP id 13mr139183rnh; Thu, 06 Jan 2005 05:04:04 -0800 (PST) Received: by 10.38.179.58 with HTTP; Thu, 6 Jan 2005 05:04:04 -0800 (PST) Message-ID: <1f2ed5cd050106050455c75c9d@mail.gmail.com> Date: Thu, 6 Jan 2005 14:04:04 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: Posted PaceEnclosuresAndPix Cc: Atom WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd050105162514f7773f@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1 it is then. (with multiples, and including the aspect ratio/resize hint - that seems good pragmatism) On Wed, 05 Jan 2005 17:04:39 -0800, Tim Bray wrote: > On Jan 5, 2005, at 4:25 PM, Danny Ayers wrote: > > > 1. If the media object is the primary content of the entry (which > > seems to be the main use case for RSS 2.0's ), shouldn't it > > be delivered using some form of the element? > > I used to think that, but we observe in the RSS2 world that there's a > well-accepted use case for something that's specially designated for > different handling. Why fight it? > > > 2. Without multiple rel="enclosure", how does support and > > differentiate between media objects that are essentially the same > > resource but different formats, where the difference may not (easily) > > be expressed using mime types? Example: > > I'm pretty well convinced that multiples can't hurt. > > > 3. I don't think this Pace is the right place for listing what should > > go in the registry - separation of concerns and all that > > That's because it's done as a delta to FieldingLinks, the new languages > goes in a couple of places in that section so I just preserved it. > > > 4. What do we call an inline (i.e. base64 encoded content) media > > object - an attachment? > > Nope, that's just -Tim > > -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Jan 6 10:06: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 KAA13501 for ; Thu, 6 Jan 2005 10:06: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 j06Eo5Np003408; Thu, 6 Jan 2005 06:50: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 j06Eo5w3003407; Thu, 6 Jan 2005 06:50:05 -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 j06Eo4cb003374 for ; Thu, 6 Jan 2005 06:50:05 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so564903rnz for ; Thu, 06 Jan 2005 06:50: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=Z5tqYTRxuuNjlV5Sr7xX2M0UAnqnhBWYIsTafMjQQzxuAvf5IJAtXapZmERUhhusShO+1HjabhvHHxp2+RWz50F8xXGVh/CUbYMDTReHYDRb3XqhQ5CjyYFsA8SN//P+wKYYJBFMosSPJoCVmq+n8Hh08Pj68FlzaarCmasnQ6M= Received: by 10.38.25.1 with SMTP id 1mr109141rny; Thu, 06 Jan 2005 06:50:03 -0800 (PST) Received: by 10.38.179.58 with HTTP; Thu, 6 Jan 2005 06:50:03 -0800 (PST) Message-ID: <1f2ed5cd0501060650610cc8a2@mail.gmail.com> Date: Thu, 6 Jan 2005 15:50:03 +0100 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: Re: The Atom Format end-game Cc: danbri@w3.org, Tim.Bray@Sun.COM 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 Wed, 05 Jan 2005 17:26:02 -0800, Tim Bray wrote: > > This represents the result of discussions between Paul and myself, and > is our position as co-chairs of the Atompub WG. > > Beginning with the conclusion: > > 1. We *must* finalize the format. Our deadline is drawing near and we > need to focus on the publishing protocol. > 2. We are close to RSS2 feature-compatibility, we either adopt image & > enclosure or make a conscious decision not to. > 3. Based on the detailed analysis below from the mailing list, there is > rough consensus that the only remaining point we MUST settle in the > format is extensibility. Likely MustIgnore can gain consensus support > via PaceExtendingAtom, perhaps with some fine-tuning. Which leaves > MustUnderstand. It is possible that PaceMustUnderstandElement might > get in if we either convince Joe Gregorio or decide to declare rough > consensus over his objections. Or maybe not. Co-chairs can live with > either. Agreed, apart from the latter part of 3. Regarding extensibility, don't forget that mustUnderstand/mustIgnore is not the only game in town. Directly related is the point that feature-parity with RSS 1.0 should be considered as well as parity with RSS 2.0. The issues raised in Tony Hammond's paper on science publishing [1] have yet to be addressed. (Note I'm not talking of replacing mustUnderstand, just that it doesn't cover what's needed in this context). Googling "site:www.imc.org extensibility" or better still "site:www.imc.org extensibility rdf" seems to yield a lot of the relevant posts on-list, e.g. [2] from Dan Brickley who has a few samples to test the extensibility of Atom. The potential benefits of RSS 1.0-like extensibility have often been stated on-list. One regular counter-argument has been along the lines of "I don't see what that buys us" (usually from Dare ;-), which has usually prompted yet another rewording of what it does buy us. The other common counter-arguments have been essentially "it's not worth the model complication"/"it's not worth the syntax complication". RDF/XML syntax was rejected before the IETF group was even set up, all the proposals since have only involved at most minor changes to the way the syntax is now. In terms of model, there is a strong argument that reference to an RDF model, even if it is only informative, can make the core Atom model clearer (was it mnot made this point early on?). RSS 1.0 demonstrates that an XML syntax mapped to a common model can disambiguate extensions. But Atom extensibility doesn't necessarily have to be defined in terms of the RDF model anyway to get these benefits (though it would IMHO be the easiest approach). Structural rules relating a constrained XML syntax of extensions to the Atom conceptual model (as described in the charter) could provide virtually the same benefits. The rules could be almost trivially simple, e.g. "child elements of an are always properties of that entry". As evidence why we need to consider this prior to Atom version 1.0, I'd point to all the (occasionally heated) disagreement surrounding extension of the element in RSS 2.0 (starting with the multiple elements issue, but then more generally e.g. see [3]). Having a common structural framework in the XML syntax would have led to improved consistency rather than conflict due to distributed ad hoc-ness. Even if several different vocabularies were used for the same kinds of data, mapping between them would be considerably easier. Whatever happens it will be possible to fire Atom XML through XSLT to produce RDF/XML (probably largely RSS 1.0). But without a consistent way of interpreting extensions, that data will be unavailable to RDF tools. But this is only a secondary concern. If structural interpretation of the syntax is consistent, then life will be easier for all application developers and Atom can be of maximum utility, on the peak of the effort/benefit curve. Cheers, Danny. [1] http://dlib.anu.edu.au/dlib/december04/hammond/12hammond.html [2] http://www.imc.org/atom-syntax/mail-archive/msg08539.html [3] http://groups.yahoo.com/group/rss-media/messages -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Jan 6 11: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 LAA19252 for ; Thu, 6 Jan 2005 11: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 j06FuYtt066341; Thu, 6 Jan 2005 07:56: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 j06FuYF6066333; Thu, 6 Jan 2005 07:56:34 -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 j06FuXfJ065963 for ; Thu, 6 Jan 2005 07:56:33 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 50523 invoked by uid 17064); 6 Jan 2005 15:56:26 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.251.47.186]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 6 Jan 2005 15:56:26 -0000 In-Reply-To: <1f2ed5cd0501060650610cc8a2@mail.gmail.com> References: <1f2ed5cd0501060650610cc8a2@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <770A815A-5FFB-11D9-8C3F-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Danny Ayers From: Henry Story Subject: Re: The Atom Format end-game Date: Thu, 6 Jan 2005 16:56:02 +0100 To: "'Atom WG'" X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I have proposed that Atom can be considered as a form of RDF already [1], and have given an example of how one needs to think of it for this to be the case. The consequences of this would be that the atom syntax need not change, and that there is a clear model for extensibility of atom. Of course this just shows that the working group is very close to having what it wants. But the details need now to be checked and verified officially, and presumably some language appear in the spec as to this being officially the correct reading. I can just point to the glaring solution to the extensibility problem. I don't know what more I can do. Henry Story [1] http://www.imc.org/atom-syntax/mail-archive/msg11850.html On 6 Jan 2005, at 15:50, Danny Ayers wrote: > On Wed, 05 Jan 2005 17:26:02 -0800, Tim Bray wrote: >> >> This represents the result of discussions between Paul and myself, and >> is our position as co-chairs of the Atompub WG. >> >> Beginning with the conclusion: >> >> 1. We *must* finalize the format. Our deadline is drawing near and we >> need to focus on the publishing protocol. >> 2. We are close to RSS2 feature-compatibility, we either adopt image & >> enclosure or make a conscious decision not to. >> 3. Based on the detailed analysis below from the mailing list, there >> is >> rough consensus that the only remaining point we MUST settle in the >> format is extensibility. Likely MustIgnore can gain consensus >> support >> via PaceExtendingAtom, perhaps with some fine-tuning. Which leaves >> MustUnderstand. It is possible that PaceMustUnderstandElement might >> get in if we either convince Joe Gregorio or decide to declare rough >> consensus over his objections. Or maybe not. Co-chairs can live with >> either. > > Agreed, apart from the latter part of 3. > > Regarding extensibility, don't forget that mustUnderstand/mustIgnore > is not the only game in town. Directly related is the point that > feature-parity with RSS 1.0 should be considered as well as parity > with RSS 2.0. The issues raised in Tony Hammond's paper on science > publishing [1] have yet to be addressed. > > (Note I'm not talking of replacing mustUnderstand, just that it > doesn't cover what's needed in this context). > > Googling "site:www.imc.org extensibility" or better still > "site:www.imc.org extensibility rdf" seems to yield a lot of the > relevant posts on-list, e.g. [2] from Dan Brickley who has a few > samples to test the extensibility of Atom. > > The potential benefits of RSS 1.0-like extensibility have often been > stated on-list. One regular counter-argument has been along the lines > of "I don't see what that buys us" (usually from Dare ;-), which has > usually prompted yet another rewording of what it does buy us. > > The other common counter-arguments have been essentially "it's not > worth the model complication"/"it's not worth the syntax > complication". RDF/XML syntax was rejected before the IETF group was > even set up, all the proposals since have only involved at most minor > changes to the way the syntax is now. In terms of model, there is a > strong argument that reference to an RDF model, even if it is only > informative, can make the core Atom model clearer (was it mnot made > this point early on?). RSS 1.0 demonstrates that an XML syntax mapped > to a common model can disambiguate extensions. > > But Atom extensibility doesn't necessarily have to be defined in terms > of the RDF model anyway to get these benefits (though it would IMHO be > the easiest approach). Structural rules relating a constrained XML > syntax of extensions to the Atom conceptual model (as described in the > charter) could provide virtually the same benefits. The rules could be > almost trivially simple, e.g. "child elements of an are always > properties of that entry". > > As evidence why we need to consider this prior to Atom version 1.0, > I'd point to all the (occasionally heated) disagreement surrounding > extension of the element in RSS 2.0 (starting with the > multiple elements issue, but then more generally e.g. see [3]). Having > a common structural framework in the XML syntax would have led to > improved consistency rather than conflict due to distributed ad > hoc-ness. Even if several different vocabularies were used for the > same kinds of data, mapping between them would be considerably easier. > > Whatever happens it will be possible to fire Atom XML through XSLT to > produce RDF/XML (probably largely RSS 1.0). But without a consistent > way of interpreting extensions, that data will be unavailable to RDF > tools. But this is only a secondary concern. > > If structural interpretation of the syntax is consistent, then life > will be easier for all application developers and Atom can be of > maximum utility, on the peak of the effort/benefit curve. > > Cheers, > Danny. > > [1] http://dlib.anu.edu.au/dlib/december04/hammond/12hammond.html > [2] http://www.imc.org/atom-syntax/mail-archive/msg08539.html > [3] http://groups.yahoo.com/group/rss-media/messages > > -- > > http://dannyayers.com > From owner-atom-syntax@mail.imc.org Thu Jan 6 12:00: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 MAA24102 for ; Thu, 6 Jan 2005 12:00: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 j06GoNGr088530; Thu, 6 Jan 2005 08: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 j06GoNbB088527; Thu, 6 Jan 2005 08:50:23 -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 j06GoMWh088105 for ; Thu, 6 Jan 2005 08:50:22 -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 <0I9W00LRHMJKXY80@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Thu, 06 Jan 2005 17:45:20 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0I9W009A2MWV6K30@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Thu, 06 Jan 2005 17:53:19 +0100 (CET) Date: Thu, 06 Jan 2005 17:53:51 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: The Atom Format end-game In-reply-to: To: Tim Bray 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: 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 Wed, 05 Jan 2005 17:26:02 -0800, Tim Bray wrote: > It is possible that PaceMustUnderstandElement might get in if we > either convince Joe Gregorio or decide to declare rough consensus > over his objections. Not sure that it matters, and I do not speak up just to obstruct consensus, but I am, and have always been, against a 'must understand' mechanism as well. I do not think it buys as much as it takes in terms of simple implementation and such, so I'm -1 on this. > - atom:updated is currently required. I think this will lead to it > being polluted with general "Last Modified" dates, severely limiting its > usefulness. I think so as well, but anything and everything is an improvement over today's situation, so I really don't care about the date discussion anymore. People will abuse these elements with whatever type of dates their publishing software provides them with, and in most cases, that's an ambigous date no one can say anything certain about. That's the way people like it, and that's fine. > - ditto "permanent, universally unique identifier" [DON'T UNDERSTAND] I don't understand this comment either. What's wrong with the wording? > [PaceCategoryRevised ACCEPTED] +1. > - Enclosures/Images (both "favicons" and other feed- or entry-related > images): Although one might use HTML in the content to point to some of > these, for CaRP (which displays newsfeeds on webpages), I find it > extremely useful to have these in a separate element I agree. > [PaceEnclosuresAndPix ADDRESSES THIS] I just wonder; how is 'size' more interesting to consumers than 'width' and 'height'? I, as a consumer of RSS feeds have more often wondered about the resolution of the images attached to entries and such rather than their physical size in kilobytes. But it might only be me. > - Explicit entry deletion: [...] Let's do it. [PROTOCOL, NOT FORMAT] I agree about both doing it and that it belongs in the protocol. I also have some last comments to the latest format draft: 3.2.2 "atom:uri" Element I think everyone agrees that the name of this element shouldn't be 'uri' but something more coherent with the rest of the specification. I see no reason why we need a pace to express this, but if someone thinks we do, I'll create one. Why can't both this and the '3.2.3 "atom:email" Element' be Link constructs, for example? 3.5.1 "rel" Attribute [...] Link constructs MAY have a rel attribute, whose value MUST be a string [...] What's a «string»? Do we need a definition? 3.6.1 Dereferencing Identity Constructs I think this section in particular (but also a heap of others) is in desperately need of examples. 4. The "atom:feed" Element [...] Its first element child MUST be atom:head, which MAY be followed zero or more atom:entry child elements. Isn't there a 'by' too little in there, e.g.: «... which MAY be followed by zero or more atom:entry child elements». 4.2.9 "atom:generator" Element [...] The atom:generator element MAY have a "uri" attribute [...] Why doesn't this element's attributes have their own sections, like all(?) other attributes in the specification? And what's wrong with 'href'? Why isn't 'atom:generator' a Link Construct? 4.2.10 "atom:copyright" Element [[Is the following paragraph bogus amateur lawyering? The first paragraph seems sufficient.]] I agree. The first paragraph seems sufficient. 4.2.11 "atom:info" Element I think this needs some explanation. Examples are nice. 5.2 "atom:link" Element atom:entry elements MUST contain at least one atom:link element with a rel attribute value of "alternate". Wasn't PaceContentOrLink accepted, so that 'atom:link' is only required in 'atom:entry' if 'atom:content' is missing? 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. I'd like to see it combined with 'lang' as well: «atom:entry elements MUST NOT contain more than one atom:link element with a rel attribute value of "alternate" that has the same type and lang attribute value». -- 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 Thu Jan 6 12:29: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 MAA26048 for ; Thu, 6 Jan 2005 12: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 j06HIhZ2019498; Thu, 6 Jan 2005 09:18: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 j06HIhYR019496; Thu, 6 Jan 2005 09:18:43 -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] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j06HIhNF019128 for ; Thu, 6 Jan 2005 09:18:43 -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 <2005010617181101400gkcl2e>; Thu, 6 Jan 2005 17:18:11 +0000 Date: Thu, 6 Jan 2005 10:18:10 -0700 Subject: To RDF or not to RDF, that is the (perennial) question 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: <1f2ed5cd0501060650610cc8a2@mail.gmail.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, January 6, 2005, at 07:50 AM, Danny Ayers wrote: > The potential benefits of RSS 1.0-like extensibility have often been > stated on-list. One regular counter-argument has been along the lines > of "I don't see what that buys us" (usually from Dare ;-), which has > usually prompted yet another rewording of what it does buy us. Part of the problem is that the benefits of RDF are often explained in language that, while I assume it's clear to people conversant with RDF, is only vaguely comprehensible, and that with effort, to those of us who aren't. From time to time I catch a glimpse of the value of RDF, but I doubt that I've ever really seen the big picture. I see two pages on the wiki addressing the RDF or not question (http://www.intertwingly.net/wiki/pie/NoToRdf and http://www.intertwingly.net/wiki/pie/XmlAndRdf), but neither strikes me as being a good "the big picture of RDF benefits for non-RDF speakers" page. Another part of the problem is that some people simply don't care about the benefits that RDF offers. While I'm sure the benefits are more than worth cost of RDF syntax to those who do care about those benefits, they are not for those who don't. Is there a way to reconcile the needs of the two groups? I see four possible futures: 1) Atom does not use RDF and is not defined and constrained in a way that makes it easy to convert to RDF (including elements from other namespaces). This would make Atom significantly less useful to those who care about RDF's benefits. 2) Atom does not use RDF, but it is defined and constrained in ways that make it easy to convert to RDF (including extensions). This should be at least minimally acceptable to pretty much everyone. 3) Atom uses RDF, adding a lot of syntactic overhead and/or variability to its structure. This would make Atom significantly less appealing to those who aren't conversant with RDF and/or using RDF-aware tools. 4) Atom uses RDF, but the way documents are structured is constrained to a subset of how RDF can be structured so that it doesn't require RDF-aware tools to process, and the amount of overhead added by the RDF syntax is minimal. This should be at least minimally acceptable to pretty much everyone. Which of #1 and #2 are we closest to right now? Is #2 or #4 achievable? If so, which is preferable? I'd like to aim for #2, but if the overhead and obfuscation in the eyes of non-RDF speakers of #4 is truly minimal (I suspect that RDF speakers and non-RDF speakers would have very different definitions of "truly minimal"), I'd have no complaints about going that route. Also, in either case, if working toward a particular solution significantly increases our time to completion, that's a major strike against it. From owner-atom-syntax@mail.imc.org Thu Jan 6 12:39: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 MAA26724 for ; Thu, 6 Jan 2005 12: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 j06HUmF3029867; Thu, 6 Jan 2005 09:30: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 j06HUm3Y029865; Thu, 6 Jan 2005 09:30:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail58-s.fg.online.no (mail58-s.fg.online.no [148.122.161.58]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j06HUlr2029697 for ; Thu, 6 Jan 2005 09:30:47 -0800 (PST) (envelope-from arve@virtuelvis.com) Received: from mail.online.no (ti132110a080-21463.bb.online.no [80.212.83.219]) by mail58.fg.online.no (8.12.11/8.12.11) with ESMTP id j06HUZpj003242; Thu, 6 Jan 2005 18:30:39 +0100 (MET) To: =?iso-8859-15?Q?Asbj=F8rn_Ulsberg?= Cc: Atom-syntax Subject: Re: The Atom Format end-game References: Message-ID: Date: Thu, 06 Jan 2005 18:30:39 +0100 From: "Arve Bersvendsen" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: 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 Thu, 06 Jan 2005 17:53:51 +0100, Asbjørn Ulsberg wrote: >> - Explicit entry deletion: [...] Let's do it. [PROTOCOL, NOT FORMAT] > > I agree about both doing it and that it belongs in the protocol. Hm. I think there may be some confusion here: - Actually deleting an entry can be done with HTTP DELETE. Which is RESTFUL - Informing your subscribers that an entry resource has been retracted/deleted is an entirely different matter, and does, IMHO belong in format, rather than protocol. -- Arve Bersvendsen http://www.bersvendsen.com/ / http://www.virtuelvis.com/ From owner-atom-syntax@mail.imc.org Thu Jan 6 12: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 MAA27099 for ; Thu, 6 Jan 2005 12:47: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 j06HbWhf035032; Thu, 6 Jan 2005 09:37: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 j06HbWmB035029; Thu, 6 Jan 2005 09:37: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.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j06HbVeC034967 for ; Thu, 6 Jan 2005 09:37:32 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id r35so60773rna for ; Thu, 06 Jan 2005 09:37: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=gei427e0/sCDbwLbfwRCIdutTGH5Y/ICAwEpfw2hNs4Y7560kB6Z1LQNXqeXS+s5ySLDDmOphkGZO1ra9j49Tu+U8kpBg8R1dmYa7YnrY4P4F9TLYxsUWx8tpPPCTBmw3hLwDvk39yQdZIdyTJ/bHSfYOfakl5ySteSVPseinys= Received: by 10.38.86.28 with SMTP id j28mr126684rnb; Thu, 06 Jan 2005 09:37:29 -0800 (PST) Received: by 10.38.72.20 with HTTP; Thu, 6 Jan 2005 09:37:29 -0800 (PST) Message-ID: <2bcdc7c405010609374df235f3@mail.gmail.com> Date: Thu, 6 Jan 2005 09:37:29 -0800 From: James Snell Reply-To: James Snell To: Atom WG Subject: Hash for Links [Was: Re: Posted PaceEnclosuresAndPix] Cc: Tim Bray In-Reply-To: <1f2ed5cd050106050455c75c9d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd050105162514f7773f@mail.gmail.com> <1f2ed5cd050106050455c75c9d@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Pardon me for stepping in on this conversation in the middle, but it has brought to mind a question about whether or not Atom should support the ability to specify a hash value for resources linked to using the link mechanism. The link can be used, for instance, to verify whether or not the resource being linked to has been modified since the link was created. This is particularly relevant to enclosures which may be of arbitrary content type and involve the user downloading bytes to their computers. Perhaps we should add two new attributes to the link element? The hash and hashalg attributes would be optional but MUST appear together. Thoughts? (If we have more than two people respond favorably to this, I'll write up a Pace for it) On Thu, 6 Jan 2005 14:04:04 +0100, Danny Ayers wrote: > > +1 it is then. > > (with multiples, and including the aspect ratio/resize hint - that > seems good pragmatism) > > > On Wed, 05 Jan 2005 17:04:39 -0800, Tim Bray wrote: > > On Jan 5, 2005, at 4:25 PM, Danny Ayers wrote: > > > > > 1. If the media object is the primary content of the entry (which > > > seems to be the main use case for RSS 2.0's ), shouldn't it > > > be delivered using some form of the element? > > > > I used to think that, but we observe in the RSS2 world that there's a > > well-accepted use case for something that's specially designated for > > different handling. Why fight it? > > > > > 2. Without multiple rel="enclosure", how does support and > > > differentiate between media objects that are essentially the same > > > resource but different formats, where the difference may not (easily) > > > be expressed using mime types? Example: > > > > I'm pretty well convinced that multiples can't hurt. > > > > > 3. I don't think this Pace is the right place for listing what should > > > go in the registry - separation of concerns and all that > > > > That's because it's done as a delta to FieldingLinks, the new languages > > goes in a couple of places in that section so I just preserved it. > > > > > 4. What do we call an inline (i.e. base64 encoded content) media > > > object - an attachment? > > > > Nope, that's just -Tim > > > > > > > -- > > http://dannyayers.com > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Thu Jan 6 12:47: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 MAA27139 for ; Thu, 6 Jan 2005 12:47: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 j06Hd6Q6037546; Thu, 6 Jan 2005 09:39: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 j06Hd68M037545; Thu, 6 Jan 2005 09:39: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] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j06Hd5S9036437 for ; Thu, 6 Jan 2005 09:39: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 (sccrmhc12) with SMTP id <2005010617383301200onfele>; Thu, 6 Jan 2005 17:38:33 +0000 Date: Thu, 6 Jan 2005 10:38:27 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: RSS feature parity 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 Do we have reference RSS 1.0 and 2.0 documents that contain every feature we want to ensure that Atom can duplicate? If not, it might be useful to create such documents, and create the Atom equivalents of them. Such documents should not contain anything that we decide Atom need not duplicate (esoteric extensions or whatever) to ensure that it's as easy as possible to compare them. They should have a few items/entries, but not too many (not so few that it's hard to imagine a feed with a lot, but not more than necessary to imagine a feed with more). Having such documents would also make for an easy way to suggest and compare alternative Atom syntaxes. For example, someone advocating an RDF-based Atom syntax could create an RDF-based Atom example document showing how it could be done. That would give us something concrete and complete to compare to the current state of Atom, and would probably make discussion of the issues more clear. Antone From owner-atom-syntax@mail.imc.org Thu Jan 6 12:53: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 MAA27587 for ; Thu, 6 Jan 2005 12: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 j06HhuOd043094; Thu, 6 Jan 2005 09:43: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 j06HhuBr043093; Thu, 6 Jan 2005 09:43: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 j06HhuA5043080 for ; Thu, 6 Jan 2005 09:43:56 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 40429 invoked by uid 17064); 6 Jan 2005 17:43:59 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.253.244.153]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 6 Jan 2005 17:43:59 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7DE36F95-600A-11D9-8C3F-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: "'Atom WG'" From: Henry Story Subject: Re: To RDF or not to RDF, that is the (perennial) question Date: Thu, 6 Jan 2005 18:43:36 +0100 To: Antone Roundy X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit To restate my point in your terms I believe I have shown that your point (4) is currently true. Ie (4) is not a future. It is currently and actually true. Like RSS1.0 Atom is a constrained form of RDF. But unlike RSS1.0 it is very inconspicuously so. IE. Anyone just looking at atom would never guess that it is RDF. I have tried to show this in an e-mail [1] to this list. Of course it would require more work to show this definitively to be the case. I have not gone through the details of this work because I'd like to have the backing of the group to do this officially, before I spend too much time on it. Also I would probably find a lot of people a lot more knowledgeable than me to help on this task if there was a declared interest. Henry Story [1] http://www.imc.org/atom-syntax/mail-archive/msg11850.html I later found ways around most (all?) of the problems I had identified in that mail on the atom-owl mailing list. On 6 Jan 2005, at 18:18, Antone Roundy wrote: > I see four possible futures: > > 1) Atom does not use RDF and is not defined and constrained in a way > that makes it easy to convert to RDF (including elements from other > namespaces). This would make Atom significantly less useful to those > who care about RDF's benefits. > > 2) Atom does not use RDF, but it is defined and constrained in ways > that make it easy to convert to RDF (including extensions). This > should be at least minimally acceptable to pretty much everyone. > > 3) Atom uses RDF, adding a lot of syntactic overhead and/or > variability to its structure. This would make Atom significantly less > appealing to those who aren't conversant with RDF and/or using > RDF-aware tools. > > 4) Atom uses RDF, but the way documents are structured is constrained > to a subset of how RDF can be structured so that it doesn't require > RDF-aware tools to process, and the amount of overhead added by the > RDF syntax is minimal. This should be at least minimally acceptable > to pretty much everyone. From owner-atom-syntax@mail.imc.org Thu Jan 6 13:02: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 NAA28139 for ; Thu, 6 Jan 2005 13:02: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 j06HpGrI052727; Thu, 6 Jan 2005 09:51: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 j06HpGfm052726; Thu, 6 Jan 2005 09:51:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from S13.MAIL.X-PORT.NET (ns2.x-portsupport.net [83.219.59.37] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j06HpFMm052505 for ; Thu, 6 Jan 2005 09:51:16 -0800 (PST) (envelope-from mark.birbeck@x-port.net) Received: from S009 ([195.40.123.90] unverified) by S13.MAIL.X-PORT.NET with Microsoft SMTPSVC(5.0.2195.5329); Thu, 6 Jan 2005 17:50:36 +0000 Received: FROM [81.157.176.3] BY S009 with hMailServer ; 6-Jan-2005 17:51:02 +0100 From: "Mark Birbeck" To: "'Antone Roundy'" Cc: Subject: RE: To RDF or not to RDF, that is the (perennial) question Date: Thu, 6 Jan 2005 17:50:56 -0000 Message-ID: <019d01c4f418$46093ee0$6f01a8c0@W100> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <8A80E87B-E83C-431E-8B92-36D528D213BB@S009> X-OriginalArrivalTime: 06 Jan 2005 17:50:36.0937 (UTC) FILETIME=[3A65F790:01C4F418] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j06HpGMm052704 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Antone, > 4) Atom uses RDF, but the way documents are structured is constrained > to a subset of how RDF can be structured so that it doesn't require > RDF-aware tools to process, and the amount of overhead added > by the RDF > syntax is minimal. This should be at least minimally acceptable to > pretty much everyone. I've been meaning to post the following link to this list for a while, but have been "just too busy", as they say: Anyway, just briefly, it is a proposal for new syntax for RDF. It's come out of the work I've been doing as an Invited Expert on the HTML Working Group, where we have restructured the metadata 'story' for HTML for XHTML 2. This syntax is actually going to be part of XHTML 2. It has been reviewed and quite well received by the RDF community, and I think it is pretty much your option 4. It is discussed on this list: I do have a number of comments on how I think it could work for Atom, although I'm afraid I'll have to leave those for another time. I just thought it worth bringing this document to your attention at least, to show that there is some momentum for an easier RDF syntax. (Although those not familiar with RDF may still find the actual specification a little tricky -- but the actual resulting mark-up is not.) Regards, Mark Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ Download our XForms processor from http://www.formsPlayer.com/ From owner-atom-syntax@mail.imc.org Thu Jan 6 13:36: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 NAA29993 for ; Thu, 6 Jan 2005 13:36: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 j06IR2fg088101; Thu, 6 Jan 2005 10:27: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 j06IR1Sv088088; Thu, 6 Jan 2005 10:27: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 j06IQw2x088034; Thu, 6 Jan 2005 10:26:59 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7DE36F95-600A-11D9-8C3F-000A95D9FA7A@bblfish.net> References: <7DE36F95-600A-11D9-8C3F-000A95D9FA7A@bblfish.net> Date: Thu, 6 Jan 2005 10:27:00 -0800 To: Henry Story , Antone Roundy From: Paul Hoffman / IMC Subject: Re: To RDF or not to RDF, that is the (perennial) question 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 6:43 PM +0100 1/6/05, Henry Story wrote: >To restate my point in your terms I believe I have shown that your >point (4) is currently true. Ie (4) is not a future. It is currently >and actually true. > >Like RSS1.0 Atom is a constrained form of RDF. But unlike RSS1.0 it >is very inconspicuously so. IE. Anyone just looking at atom would >never guess that it is RDF. > >I have tried to show this in an e-mail [1] to this list. Of course >it would require more work to show this definitively to be the case. >I have not gone through the details of this work because I'd like to >have the backing of the group to do this officially, before I spend >too much time on it. Also I would probably find a lot of people a >lot more knowledgeable than me to help on this task if there was a >declared interest. Wearing my co-chair hat, the reason I didn't give backing is that I didn't hear much desire for it. That is not to say you shouldn't do it, just that it was not needed to be a WG work item. It is quite common in the IETF that there are set of WG work items *and* individually-submitted drafts that extend, explain, or otherwise refer to the WG work items. If you wanted to create a draft that would eventually become an Informational RFC that explained how the Atom format as we are discussing it relates to RDF, I'm sure that would be useful to some people (and possibly many more than we can imagine right now). So, instead of me saying "feel free to do it", let me encourage you to do it. It doesn't affect the WG products or timelines, but could have a positive effect of eventual Atom use. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Jan 6 15:02: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 PAA10923 for ; Thu, 6 Jan 2005 15:02: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 j06JnIm4069074; Thu, 6 Jan 2005 11:49: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 j06JnIlP069072; Thu, 6 Jan 2005 11:49: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 j06JnH9p068996 for ; Thu, 6 Jan 2005 11:49: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 j06JmbM7026795; Thu, 6 Jan 2005 19:48:38 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6-32183803; protocol="application/pkcs7-signature" Message-Id: Cc: Tim Bray , Atom-Syntax From: Graham Subject: Re: The Atom Format end-game Date: Thu, 6 Jan 2005 19:48:38 +0000 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= X-Mailer: Apple Mail (2.619) 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-32183803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 6 Jan 2005, at 4:53 pm, Asbj=F8rn Ulsberg wrote: >> - ditto "permanent, universally unique identifier" [DON'T=20 >> UNDERSTAND] > > I don't understand this comment either. What's wrong with the wording? The full phrase is: "permanent, universally unique identifier for the construct's parent" This could, in good faith, be interpreted to require a random number=20 generator: - Permanent: I have no way to change it after I've transmitted it - Universally unique: Yes - The construct's parent: I'm taking this to mean this the XML chunk=20 I've just generated, and it identifies that for you just fine It is not "universally unique", it is unique to instances of the entry=20= being described. Similarly "permanent" is redundant in the same way=20 that describing values as "change"-able is nonsense. Compare with what=20= I wrote for PaceIDConstruct2: Identification Constructs convey an identifier that is used to associate different instances of the same resource. Whenever a resource appears in an Atom Document, its identifier SHOULD be the same as any other times it has appeared in an Atom Document, and MUST NOT be the same as the identifier currently or formerly used for any other Atom resource. Changes to the content or location of the resource MUST NOT change the identifier. All Atom Documents published by the same entity MUST use the same identifier for each respective resource they publish. It's still not perfect, but it actually gets across what we mean. Graham= --Apple-Mail-6-32183803 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 9w0BCQUxDxcNMDUwMTA2MTk0ODM5WjAjBgkqhkiG9w0BCQQxFgQUGJdvjUxHTHAwVBqlM6qrfzVl XB8weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAWG1r5XnVAea77jbJ/0/iBUXF huQKpZvL96iiKEGL+OGV/5o/XOU1Zr9XbMHNBuHcZ53IHmEJBzUkKM4l23/pWeGTVqzbAse9QBNO Sv5gueM6swYlPzJXQbJ78Ybk3DXwU2Z5mO85USAu46xchbM5SVJRHHHZb92L/HfhiC2xCXIUTieg WOvIbji+h7e+3fcFmnRJsP3AL8Eh50sD18yARyJLS73cZv+xWlwRGcADykLpvgyTMtW4xvM7wO/a Bp9VC4mDf5zZEQMFWx0GyC3uCR9cIGl2oKkEupxVLHTU7PIgMiYyVBjGu5H/70efBJKtYURm8Dkf 6vr8F6dqjmuJBQAAAAAAAA== --Apple-Mail-6-32183803-- From owner-atom-syntax@mail.imc.org Thu Jan 6 20:13: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 UAA11582 for ; Thu, 6 Jan 2005 20:13: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 j070qqE0087842; Thu, 6 Jan 2005 16:52: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 j070qqot087841; Thu, 6 Jan 2005 16:52:52 -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 j070qo12087826 for ; Thu, 6 Jan 2005 16:52:51 -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 <0I9X00M0K8VTUW60@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Fri, 07 Jan 2005 01:47:53 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0I9X00A73993OC40@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Fri, 07 Jan 2005 01:55:52 +0100 (CET) Date: Fri, 07 Jan 2005 01:56:24 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: The Atom Format end-game In-reply-to: To: Graham Cc: Tim Bray , 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: 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 Thu, 6 Jan 2005 19:48:38 +0000, Graham wrote: > The full phrase is: > "permanent, universally unique identifier for the construct's parent" > > This could, in good faith, be interpreted to require a random number > generator: > - Permanent: I have no way to change it after I've transmitted it > - Universally unique: Yes A random number might be globally unique but not universally. Maybe we need to explain the difference? Globally unique is unique within the moment of time the ID is generated. Universally unique is unique at that time and «forever». > - The construct's parent: I'm taking this to mean this the XML chunk > I've just generated, and it identifies that for you just fine Could you be more specific about how you interpret it? Examples would be nice. > It is not "universally unique", it is unique to instances of the entry > being described. Within what context? Anyway; if it's not universally unique, it doesn't comply to the specification and thus is no good. The risque of two entries having the same ID is too high when an ID is not either of «permanent» or «universally unique». > Similarly "permanent" is redundant in the same way that describing values > as "change"-able is nonsense. How is it redundant? People change these things all the time. What magic have been done that have made them stop? > Identification Constructs convey an identifier that is used > to associate different instances of the same resource. > Whenever a resource appears in an Atom Document, its > identifier SHOULD be the same as any other times it has > appeared in an Atom Document, and MUST NOT be the same as the > identifier currently or formerly used for any other Atom > resource. Changes to the content or location of the resource > MUST NOT change the identifier. All Atom Documents published > by the same entity MUST use the same identifier for each > respective resource they publish. This only seems to suggest that two entries within the same feed shouldn't have the same identifier, and doesn't deal with syndication-related problems with identifiers at all. With your text proposal, I think it looks all right to have ID's match cross-feed, no matter whether they're the same entry or not. I don't think that's okay. > It's still not perfect, but it actually gets across what we mean. Maybe it gets across what you mean, but not what I do. -- 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 Thu Jan 6 21:08: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 VAA17400 for ; Thu, 6 Jan 2005 21:08: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 j071w7gc095859; Thu, 6 Jan 2005 17:58: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 j071w7Xt095858; Thu, 6 Jan 2005 17:58: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 j071w6Lt095848 for ; Thu, 6 Jan 2005 17:58:06 -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 j071vFA4012096; Fri, 7 Jan 2005 01:57:16 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7-54301249; protocol="application/pkcs7-signature" Message-Id: <74E89186-604F-11D9-B651-000A95DC3D90@mac.com> Cc: Tim Bray , Atom-Syntax From: Graham Subject: Re: The Atom Format end-game Date: Fri, 7 Jan 2005 01:57:16 +0000 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= X-Mailer: Apple Mail (2.619) 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-54301249 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 7 Jan 2005, at 12:56 am, Asbj=F8rn Ulsberg wrote: > A random number might be globally unique but not universally. Maybe we=20= > need to explain the difference? Globally unique is unique within the=20= > moment of time the ID is generated. Universally unique is unique at=20 > that time and =ABforever=BB. Exactly my point, "universally unique" requires that all instances of=20 atom entries to have different ids, even when they contain the same=20 blog entries. (yes, a random number generator would repeat. My bad) >> - The construct's parent: I'm taking this to mean this the XML chunk >> I've just generated, and it identifies that for you just fine > > Could you be more specific about how you interpret it? Examples would=20= > be nice. A server generates XML for client A and stamps it with a number. A=20 server generates new XML for client B and therefore stamps it with a=20 new number to identify it (even though it contains the same atom=20 entry). I'm reading parent element to be the node that I just=20 created in memory. The text says nothing about the identifier belonging=20= to one blog entry. > How is it redundant? People change these things all the time. What=20 > magic have been done that have made them stop? The Atom spec describes how to assemble an XML file. How can anyone=20 insert "permanent" characters into a file, write them in blood? What we=20= want people to do is use the same identifier as the last time they=20 assembled a file, which is a whole other thing from "permanent". >> Identification Constructs convey an identifier that is used >> to associate different instances of the same resource. >> Whenever a resource appears in an Atom Document, its >> identifier SHOULD be the same as any other times it has >> appeared in an Atom Document, and MUST NOT be the same as = the >> identifier currently or formerly used for any other Atom >> resource. Changes to the content or location of the = resource >> MUST NOT change the identifier. All Atom Documents published >> by the same entity MUST use the same identifier for each >> respective resource they publish. > > This only seems to suggest that two entries within the same feed=20 > shouldn't have the same identifier, and doesn't deal with=20 > syndication-related problems with identifiers at all. TELEGRAM FOR MR A. ULSBERG: "Its identifier... MUST NOT be the same as the identifier currently or=20= formerly used for any other Atom resource" STOP Graham= --Apple-Mail-7-54301249 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 9w0BCQUxDxcNMDUwMTA3MDE1NzE2WjAjBgkqhkiG9w0BCQQxFgQUWiiWskFGQtUBl+L4umvZXOA6 0ukweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEA3FJv7a6JgowVUq1HiJXsAV8O gN7DqlJ2P42128SuJTnbIXVsRSzXWYS5kNocyOdYKR7fs4M6n6EE9PfSuQYf+5TWTzJmFiooGyjE TeUDUf5Jooqiaj2NugDY6MPq9rPkuHaYj/uvFz4B208f4L/JHW8NiteK1dEqtlHUkkFuOqTW+X5m L7FTuSasqxQJZ/C1zDeseASgX6BBc4Ofc1N5p3H4bkg/q8cojftUzNDSohEOz3ak6Om6BlGrq587 AszRJ9CPHtPciGXv9GzSg0SuGEKeHe0peHZ6ryDYwxG6Muz2tkKnZ97jy/oVy7L1SmKlabbZEP4D rOuSfKSlTqErxQAAAAAAAA== --Apple-Mail-7-54301249-- From owner-atom-syntax@mail.imc.org Thu Jan 6 23:33: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 XAA27460 for ; Thu, 6 Jan 2005 23:33: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 j074HhJQ011410; Thu, 6 Jan 2005 20:17: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 j074HhX5011407; Thu, 6 Jan 2005 20:17:43 -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 j074HglA011336 for ; Thu, 6 Jan 2005 20:17:42 -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 <2005010704174301400gcjroe>; Fri, 7 Jan 2005 04:17:44 +0000 Date: Thu, 6 Jan 2005 21:17:41 -0700 Subject: Re: The Atom Format end-game 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: <74E89186-604F-11D9-B651-000A95DC3D90@mac.com> Message-Id: <12C16E7E-6063-11D9-85FC-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 6, 2005, at 06:57 PM, Graham wrote: > Exactly my point, "universally unique" requires that all instances of > atom entries to have different ids, even when they contain the same > blog entries. ... > A server generates XML for client A and stamps it with a number. A > server generates new XML for client B and therefore stamps it with a > new number to identify it (even though it contains the same atom > entry). I'm reading parent element to be the node that I just > created in memory. The text says nothing about the identifier > belonging to one blog entry. ... > The Atom spec describes how to assemble an XML file. How can anyone > insert "permanent" characters into a file, write them in blood? What > we want people to do is use the same identifier as the last time they > assembled a file, which is a whole other thing from "permanent". > Is this a mental exercise in picking language apart and looking for all possible ways to misinterpret it, or do you really think that people seeing "permanent" are going to think that they have to open the hard drive and write on it with an indelible marker? And do you really think that people reading "universally unique" are going to think that every time they transmit an atom entry, it's a different entry, and thus needs a new ID? Even you referred to the entry transmitted to two clients as "the same atom entry". Calling it a different entry each time it's transmitted is like saying that when you and I look at a painting, we're seeing a different painting because different photons are bouncing off of it and into each of our eyes. Given that the details of how a particular server assembles data into XML and serves it to clients is an implementation detail beyond the scope of the spec (it could be done dynamically, or it could be static...), if you are reading that language as referring to "the node that [you] just created in memory", I think you're reading the spec incorrectly--that particular point is not a matter of ambiguity in the spec language. Anyway, why would you put an ID into an XML document that referred to the state of RAM in your server? By that logic, the client should be generating a new ID for the entry that it has in its own memory. Anyway, details of this particular issue aside, while there is value in tightening up the language of the spec to the point where it's impossible to come up with an internally consistent yet incorrect interpretation of it, we need to take care not to get overzealous and end up with a spec that's so verbose that it's unreadable, and thus is misinterpreted because people don't spend enough time pondering each sentence to figure out what the heck it's trying to say. And at some point, perfect is the worst enemy of good enough. Unless we really think there's a danger of misinterpretation, we'll get more benefit from finishing the spec and getting it out than from continuing to rework the trivial details of the wording. While "permanent, universally unique identifier" might perhaps be a bit too terse, "an identifier that is used to associate different instances of the same resource. Whenever a resource appears in an Atom Document, its identifier SHOULD be the same as any other times it has appeared in an Atom Document, and MUST NOT be the same as the identifier currently or formerly used for any other Atom resource" may be a bit longer than is necessary. I think making the distinction between the Atom entry and the resource that it conveys information about introduces unnecessary verbosity to the language. Borrowing lots of language from the current draft: An Identity construct is an element whose content conveys a permanent, universally unique identifier for its parent element. "Permanent" means that the its content MUST NOT change when the parent element or any element or document containing it is retransmitted, revised, relocated, migrated, syndicated, republished, exported or imported. "Universally unique" means that its content cannot have been used as the identifier for any other element in any Atom document. Its content MUST be an absolute URI [RFC2396]. From owner-atom-syntax@mail.imc.org Fri Jan 7 00:24: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 AAA00290 for ; Fri, 7 Jan 2005 00:24: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 j0758cSd071281; Thu, 6 Jan 2005 21:08: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 j0758cHI071280; Thu, 6 Jan 2005 21:08:38 -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 j0758b35071150 for ; Thu, 6 Jan 2005 21:08:38 -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 <0I9X0003ZKPXQY30@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Fri, 07 Jan 2005 06:03:33 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0I9X00A2SL38W040@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Fri, 07 Jan 2005 06:11:32 +0100 (CET) Date: Fri, 07 Jan 2005 06:12:02 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: The Atom Format end-game In-reply-to: <12C16E7E-6063-11D9-85FC-003065EA6144@geckotribe.com> To: Antone Roundy 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: <12C16E7E-6063-11D9-85FC-003065EA6144@geckotribe.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 Thu, 6 Jan 2005 21:17:41 -0700, Antone Roundy wrote: > While "permanent, universally unique identifier" might perhaps be a bit > too terse, "an identifier that is used to associate different instances > of the same resource. Whenever a resource appears in an Atom Document, > its identifier SHOULD be the same as any other times it has appeared in > an Atom Document, and MUST NOT be the same as the identifier currently > or formerly used for any other Atom resource" may be a bit longer than > is necessary. Indeed. > I think making the distinction between the Atom entry and the resource > that it conveys information about introduces unnecessary verbosity to > the language. I agree. > An Identity construct is an element whose content conveys a permanent, > universally unique identifier for its parent element. "Permanent" means > that the its content MUST NOT change when the parent element or any > element or document containing it is retransmitted, revised, relocated, > migrated, syndicated, republished, exported or imported. "Universally > unique" means that its content cannot have been used as the identifier > for any other element in any Atom document. Its content MUST be an > absolute URI [RFC2396]. Instead of «its content», I think «the identifier» is better. Thus: «"Universally unique" means that the identifier cannot have been used as the identifier for any other element in any Atom document». -- 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 Fri Jan 7 02:43: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 CAA22355 for ; Fri, 7 Jan 2005 02:43: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 j077VoW8022169; Thu, 6 Jan 2005 23: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 j077VoZo022167; Thu, 6 Jan 2005 23:31:50 -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 j077VmHQ020812 for ; Thu, 6 Jan 2005 23:31: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); Fri, 7 Jan 2005 18:30:58 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 07 Jan 2005 18:31:15 +1100 Subject: Re: The Atom Format end-game 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 6/1/05 12:26 PM, "Tim Bray" wrote: > 1. We *must* finalize the format. Our deadline is drawing near and we > need to focus on the publishing protocol. Aside from focusing on the publishing protocol, which is well due, what else happens after we finalise the format spec? Specifically, what are the IETF hoops that need to be jumped through, and what periods of diligence/comment are mandated? Or will the document we settle on at such-n-such date be the one we are completely stuck with for quite a while until we get around to working on Atom 2.0? If we want to revise 1.0, do we need to formally establish a new WG through the IETF, or just carry on from here. What I'd like to see is one last version of the spec released for trial deployment (0.9?), in the same sense that 0.3 is out there in the wild, so that we can see all the mistakes that people make interpreting the spec, what things work and don't work ... and we can then do a quick spackle and buff before announcing 1.0. Or is it a trivial matter to revisit the spec in (say) 3-6 months and quickly burp the baby to get v1.1? e. From owner-atom-syntax@mail.imc.org Fri Jan 7 03:26: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 DAA24869 for ; Fri, 7 Jan 2005 03:26: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 j078Ew8V001110; Fri, 7 Jan 2005 00: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 j078EwbI001108; Fri, 7 Jan 2005 00:14:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from imo-d22.mx.aol.com (imo-d22.mx.aol.com [205.188.144.208]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j078EvxQ000526 for ; Fri, 7 Jan 2005 00:14:57 -0800 (PST) (envelope-from Svgdeveloper@aol.com) Received: from Svgdeveloper@aol.com by imo-d22.mx.aol.com (mail_out_v37_r3.8.) id o.5b.609397b2 (4214); Fri, 7 Jan 2005 03:14:37 -0500 (EST) From: Svgdeveloper@aol.com Message-ID: <5b.609397b2.2f0f9eed@aol.com> Date: Fri, 7 Jan 2005 03:14:37 EST Subject: Re: The Atom Format end-game To: Tim.Bray@Sun.COM, atom-syntax@imc.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_5b.609397b2.2f0f9eed_boundary" X-Mailer: 8.0 for Windows sub 670 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --part1_5b.609397b2.2f0f9eed_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 1/6/2005 1:26:45 AM GMT Standard Time, Tim.Bray@Sun.COM writes: > Beginning with the conclusion: > > 1. We *must* finalize the format. Tim, Are you saying that the "format" needs to be finalised? Or that the specification document for the Atom format needs to be finalised? The way you express the "conclusion" seems to me to potentially confuse the two. If you are referring to the specification document, when do you anticipate that a further draft of the specification document might be available so that contributors to this list and lurkers can make intelligent comment on the document? > Our deadline is drawing near Whose deadline? IETF's? One suggested/imposed by you and Paul? What, expressed in UTC, is the deadline? A deadline for what? Is it a deadline for the next draft specification document or for a properly drafted specification document? When the current specification document is in a stage where it has comments like "[[ more motivation / design principles ]]" it seems to me that it may be premature to be pushing for "finalisation". If, for example, the design principles are not clearly expressed then, perhaps, it is premature to be pushing for "finalisation". I would suggest that a further draft of the specification be produced. If you seriously consider that we are close to "finalisation" then that draft should be "complete", in the sense of expressing everything that is assumed to be decided. Since the specification document is, I assume, the key deliverable it is only when we see how well that document expresses what we think (from our various points of view) has been "agreed" that it will be possible to say how close we are to be the format specification being finalised. Thanks Andrew Watt --part1_5b.609397b2.2f0f9eed_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 1/6/2005 1:26:45= AM GMT Standard Time, Tim.Bray@Sun.COM writes:

Beginning with the conclusion:<= BR>
1. We *must* finalize the format. 


Tim,

Are you saying that the "format" needs to be finalised? Or that the specific= ation document for the Atom format needs to be finalised?

The way you express the "conclusion" seems to me to potentially confuse the=20= two.

If you are referring to the specification document, when do you anticipate t= hat a further draft of the specification document might be available so that= contributors to this list and lurkers can make intelligent comment on the d= ocument?

> Our deadline is drawing near

Whose deadline? IETF's? One suggested/imposed by you and Paul? What, express= ed in UTC, is the deadline?

A deadline for what? Is it a deadline for the next draft specification docum= ent or for a properly drafted specification document? When the current speci= fication document is in a stage where it has comments like "[[ more motivati= on / design principles ]]" it seems to me that it may be premature to be pus= hing for "finalisation". If, for example, the design principles are not clea= rly expressed then, perhaps, it is premature to be pushing for "finalisation= ".

I would suggest that a further draft of the specification be produced. If yo= u seriously consider that we are close to "finalisation" then that draft sho= uld be "complete", in the sense of expressing everything that is assumed to=20= be decided.

Since the specification document is, I assume, the key deliverable it is onl= y when we see how well that document expresses what we think (from our vario= us points of view) has been "agreed" that it will be possible to say how clo= se we are to be the format specification being finalised.

Thanks

Andrew Watt
 --part1_5b.609397b2.2f0f9eed_boundary-- From owner-atom-syntax@mail.imc.org Fri Jan 7 06:39: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 GAA06805 for ; Fri, 7 Jan 2005 06:39: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 j07BNlHx013279; Fri, 7 Jan 2005 03:23: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 j07BNlnl013278; Fri, 7 Jan 2005 03:23: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 ([161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j07BNkDC012983 for ; Fri, 7 Jan 2005 03:23:46 -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 j07BLBqr001922; Fri, 7 Jan 2005 11:21:16 GMT In-Reply-To: <12C16E7E-6063-11D9-85FC-003065EA6144@geckotribe.com> References: <12C16E7E-6063-11D9-85FC-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8-88136287; protocol="application/pkcs7-signature" Message-Id: <3C2997AB-609E-11D9-B651-000A95DC3D90@mac.com> Cc: atom-syntax@imc.org From: Graham Subject: Re: The Atom Format end-game Date: Fri, 7 Jan 2005 11:21:11 +0000 To: Antone Roundy X-Mailer: Apple Mail (2.619) 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-88136287 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 7 Jan 2005, at 4:17 am, Antone Roundy wrote: > Is this a mental exercise in picking language apart and looking for > all possible ways to misinterpret it, or do you really think that > people seeing "permanent" are going to think that they have to open > the hard drive and write on it with an indelible marker? And do you > really think that people reading "universally unique" are going to > think that every time they transmit an atom entry, it's a different > entry, and thus needs a new ID? The spec says nothing about what these words mean, and if we're forcing people to guess than we are not doing our job. Neither of these words inherently mean what the Atom spec wants them to mean. They convey no useful information. > Even you referred to the entry transmitted to two clients as "the same > atom entry". The spec doesn't say identifiers are for identifying the same atom entry. If that's what we want it to, it should. > Calling it a different entry each time it's transmitted is like > saying that when you and I look at a painting, we're seeing a > different painting because different photons are bouncing off of it > and into each of our eyes. Let's take photos. The spec does not say that both our photos should have the same identifier because they're of the same photo. It does imply that we need separate identifiers because they're different photos (even if they look the same). The word "permanent" isn't useful here. > Unless we really think there's a danger of misinterpretation, we'll > get more benefit from finishing the spec and getting it out than from > continuing to rework the trivial details of the wording. This isn't trivial. The words "permanent" and "universally unique" convey as much information to someone who doesn't already know our meaning and what the element is for as if we used "lounge chair" and "dirigible". > An Identity construct is an element whose content conveys a permanent, > universally unique identifier for its parent element. "Permanent" > means that the its content MUST NOT change when the parent element or > any element or document containing it is retransmitted, revised, > relocated, migrated, syndicated, republished, exported or imported. > "Universally unique" means that its content cannot have been used as > the identifier for any other element in any Atom document. Its > content MUST be an absolute URI [RFC2396]. "change" - "be different" "parent element" - what does this mean: Every time I transmit the letters "..."? You need to refer to the underlying blog entry or whatever. I'm sorry, this once again doesn't convey any useful information as to what we mean. I'm not being malicious. As much as Dave Winer thinks so, people cannot read the spec writer's mind. The intended meaning need to be written on the page. Graham --Apple-Mail-8-88136287 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 9w0BCQUxDxcNMDUwMTA3MTEyMTExWjAjBgkqhkiG9w0BCQQxFgQUnkBuW7p8z9DmIgAvaz/dqfPp sI8weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAcJTJNQa00FLvwJQMiVEKCRo0 4Paraq25zZysTnSoPkQ0tTwOwxkPLJYQR63EiVPP7ku63mcGNqLCNceHdb3w5vW2I2aB0fNHDRc/ Bt2yGy2Ch7dOCq82MPhD+OHEFSzK35An6d3eGrSQUKQEcLcQl5P2oFfqwaKIA94+Ui2zyNEVQX4j o52//skYbmZJuiGmyadM+8rBv3e7zuAVAl2L7oafaOG2+XhFAifncrNLOPfYKgQG97gLgFiOkyb6 QK8/5NbuXVFPU0qA3RyP1azrRj+a89UbW2A9oksazwA095qlRzs4L04Okxc5te6y4GJPBOOUk7jO DkcNgHEyfpEqWAAAAAAAAA== --Apple-Mail-8-88136287-- From owner-atom-syntax@mail.imc.org Fri Jan 7 08:58: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 IAA14794 for ; Fri, 7 Jan 2005 08: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 j07Dn1XY040568; Fri, 7 Jan 2005 05:49: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 j07Dn1HJ040567; Fri, 7 Jan 2005 05:49: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.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j07Dn0oZ040515 for ; Fri, 7 Jan 2005 05:49:00 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so616136rnz for ; Fri, 07 Jan 2005 05:48: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:to:subject:mime-version:content-type:content-transfer-encoding; b=Rs6a7AZKPWY6QhB1VNl9gjMiN+oFVxGWaD4j096zWCte6S27tvPMs9g6n16qtw/L07JzcZnfuRBCOQVgRiUvvE/O9KA2eMALcq1eVoyhjFNbYHMWZgJDksoqU4mIszTBl2Rh8j0rK+u6eGGImEXuwIOVfUou6xgwKpF+wnOr8N0= Received: by 10.38.8.13 with SMTP id 13mr291064rnh; Fri, 07 Jan 2005 05:48:56 -0800 (PST) Received: by 10.38.179.58 with HTTP; Fri, 7 Jan 2005 05:48:56 -0800 (PST) Message-ID: <1f2ed5cd05010705487956cbbf@mail.gmail.com> Date: Fri, 7 Jan 2005 14:48:56 +0100 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: RSS extensibility 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 In the interests of clarification, consider this pseudo-Atom snippet, with an extension: 2005-02-15 ... Looking at the PRISM spec (which the namespace qualification identifies) - [[ embargoDate Earliest date (potentially including time) the resource may be used according to the rights agreement, or clause in the rights agreement. ]] So the human meaning of an 'embargoDate' element is reasonably clear. The problem is that with RSS 2.0's approach to extensibility, there is no relationship defined between this element and any part of the feed data. Ok, it's an embargo date. But the embargo date of what? On the other hand, following the RSS 1.0 approach to extensibility, the markup would be interpreted as RDF/XML, which assigns a role for the different parts of the XML structure. The pseudo-Atom is making the statement: _:entry prism:embargoDate "2005-02-15" . The embargoDate is unambiguously a property of the entry. In the RSS 1.0 case this is defined in the RDF model. IMHO Atom would benefit from a similar disambiguation mechanism. As Henry has suggested this could be through RDF, mapping directly between the Atom syntax and an RDF representation. This does seem the easiest way of giving Atom such a mechanism without using RDF/XML. But an Atom-specific mechanism could relatively easily be defined. The use of URIs for entries is a good start, but other structural hooks (which could make sense of the example above) could be added without any disruption of the core spec as it stands (aside from constraining how and where such extensions should appear). This general idea has been the subject of several proposals, including Sean Palmer's ExtensibilityFramework early on and the more recent properties-based approach (sorry, not got links, the Wiki is giving me 500s). I believe the basic extensibility mechanism should be part of the core spec, though any mapping to RDF might be provided as 'informative'. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Jan 7 10:07: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 KAA18888 for ; Fri, 7 Jan 2005 10:07: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 j07EsprM088821; Fri, 7 Jan 2005 06:54: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 j07EspqZ088820; Fri, 7 Jan 2005 06:54: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 j07Espxa088769 for ; Fri, 7 Jan 2005 06:54:51 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 34454 invoked by uid 17064); 7 Jan 2005 14:54:43 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.253.244.130]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 7 Jan 2005 14:54:43 -0000 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> Cc: Paul Hoffman / IMC From: Henry Story Subject: Atom extensibility Date: Fri, 7 Jan 2005 15:54:18 +0100 To: "'Atom WG'" X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j07Espxa088808 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Thanks for the encouragement. But I think this is not just something that can happen completely independently. Extensibility is part of the Atom Charter, so this is in fact important to Atom in a much more central way. The question is exactly how should the interesting discovery that an Atom document is an RDF document [Ø] be used to fulfill the charter requirements on extensibility? Clearly it could completely underpin the extensibility framework, and so allow the Atom charter to be successfully fulfilled. I am in agreement with Danny's recent post [1] that something has to go in the charter that guides this relationship. I have some ideas on how this could be done, but I would rather just ask the question in this post, and not confuse the issue with potentially misguided solutions to the problem. So perhaps we can open this thread as a place to post ideas on the topic. Henry Story [Ø] though it still remains to be formally proven [1] A similar question was just asked by Danny Ayers http://www.imc.org/atom-syntax/mail-archive/msg11918.html [2] http://www.imc.org/atom-syntax/mail-archive/msg11909.html On 6 Jan 2005, at 19:27, Paul Hoffman wrote [2]: > At 6:43 PM +0100 1/6/05, Henry Story wrote: >> To restate my point in your terms I believe I have shown that your >> point (4) is currently true. Ie (4) is not a future. It is currently >> and actually true. >> >> Like RSS1.0 Atom is a constrained form of RDF. But unlike RSS1.0 it >> is very inconspicuously so. IE. Anyone just looking at atom would >> never guess that it is RDF. >> >> I have tried to show this in an e-mail [1] to this list. Of course it >> would require more work to show this definitively to be the case. I >> have not gone through the details of this work because I'd like to >> have the backing of the group to do this officially, before I spend >> too much time on it. Also I would probably find a lot of people a >> lot more knowledgeable than me to help on this task if there was a >> declared interest. > > Wearing my co-chair hat, the reason I didn't give backing is that I > didn't hear much desire for it. That is not to say you shouldn't do > it, just that it was not needed to be a WG work item. > > It is quite common in the IETF that there are set of WG work items > *and* individually-submitted drafts that extend, explain, or otherwise > refer to the WG work items. If you wanted to create a draft that would > eventually become an Informational RFC that explained how the Atom > format as we are discussing it relates to RDF, I'm sure that would be > useful to some people (and possibly many more than we can imagine > right now). > > So, instead of me saying "feel free to do it", let me encourage you to > do it. It doesn't affect the WG products or timelines, but could have > a positive effect of eventual Atom use. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-atom-syntax@mail.imc.org Fri Jan 7 10:46: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 KAA22003 for ; Fri, 7 Jan 2005 10:46: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 j07FcCI9017038; Fri, 7 Jan 2005 07: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 j07FcC6X017036; Fri, 7 Jan 2005 07:38: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 j07FcCee016866 for ; Fri, 7 Jan 2005 07:38: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 <2005010715380901200p7ul1e>; Fri, 7 Jan 2005 15:38:09 +0000 Date: Fri, 7 Jan 2005 08:38:07 -0700 Subject: Re: RSS extensibility 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: <1f2ed5cd05010705487956cbbf@mail.gmail.com> Message-Id: <20BFE988-60C2-11D9-8D42-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 Thanks for the example--very clear. It seems to me that there are two ways to look at this: 1) To a human looking at the XML (at least to one who doesn't see through RDF-colored lenses (which, BTW, is in no way intended as a pejorative--maybe it's everyone else's lenses that are colored)), I think it's intuitively obvious that it's the embargo date of the entry. 2) However, technically, nothing in the spec explicitly says that that's the case. I suspect that #2 is important to many of us, but that many others of us don't care about #2, because #1 is sufficient for us. I also suspect that the former will not be made to cease caring and that the latter will not be made to begin caring by any amount of discussion. This brings us back to the question of how to serve the needs of both groups. Can Atom be made RDF (or can we agree that it already is RDF...and can RDF processing tools handle it as such) with minimal syntactic overhead and no risk of XML structure requiring an RDF-aware parser? Or (ignoring the possibility of other approaches) can we make Atom extremely easy to convert to RDF without ambiguity like what is mentioned below? On Friday, January 7, 2005, at 06:48 AM, Danny Ayers wrote: > In the interests of clarification, consider this pseudo-Atom snippet, > with an extension: > > xmlns:prism="http://prismstandard.org/namespaces/1.2/basic/"> > > > 2005-02-15 > ... > > > > > Looking at the PRISM spec (which the namespace qualification > identifies) - > [[ > embargoDate > Earliest date (potentially including time) the resource may be used > according to the rights agreement, or clause in the rights agreement. > ]] > > So the human meaning of an 'embargoDate' element is reasonably clear. > The problem is that with RSS 2.0's approach to extensibility, there is > no relationship defined between this element and any part of the feed > data. Ok, it's an embargo date. But the embargo date of what? > > On the other hand, following the RSS 1.0 approach to extensibility, > the markup would be interpreted as RDF/XML, which assigns a role for > the different parts of the XML structure. The pseudo-Atom is making > the statement: > > _:entry prism:embargoDate "2005-02-15" . > > The embargoDate is unambiguously a property of the entry. In the RSS > 1.0 case this is defined in the RDF model. > > IMHO Atom would benefit from a similar disambiguation mechanism. From owner-atom-syntax@mail.imc.org Fri Jan 7 10:52: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 KAA22317 for ; Fri, 7 Jan 2005 10:52: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 j07FilcM023664; Fri, 7 Jan 2005 07:44: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 j07FilBs023663; Fri, 7 Jan 2005 07:44:47 -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 j07FikWs023647 for ; Fri, 7 Jan 2005 07:44:46 -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 j07FimVu004221 for ; Fri, 7 Jan 2005 08:44:48 -0700 (MST) Received: from xpa-fe1 (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 <0I9Y006J5EENBP@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 07 Jan 2005 08:44:48 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9Y00H0YEEN9I@mail.sun.net> for atom-syntax@imc.org; Fri, 07 Jan 2005 08:44:47 -0700 (MST) Date: Fri, 07 Jan 2005 07:44:46 -0800 From: Tim Bray Subject: Re: RSS extensibility In-reply-to: <1f2ed5cd05010705487956cbbf@mail.gmail.com> To: Danny Ayers Cc: atom-syntax@imc.org Message-id: <0EB0A912-60C3-11D9-A2C8-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: <1f2ed5cd05010705487956cbbf@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 7, 2005, at 5:48 AM, Danny Ayers wrote: > xmlns:prism="http://prismstandard.org/namespaces/1.2/basic/"> > > 2005-02-15 > ... > > > > [[ > embargoDate > Earliest date (potentially including time) the resource may be used > according to the rights agreement, or clause in the rights agreement. > ]] > > So the human meaning of an 'embargoDate' element is reasonably clear. > The problem is that with RSS 2.0's approach to extensibility, there is > no relationship defined between this element and any part of the feed > data. Ok, it's an embargo date. But the embargo date of what? The embargo date of the entry. This seems painfully obvious, and any other reading would be willfully contrary. Either software understands what embargoDate means or it doesn't, and if it does, well then, it'll embargo the entry, and if not, not. I have not seen any evidence that these RDF incantations have any relation to the needs of implementors. -Tim From owner-atom-syntax@mail.imc.org Fri Jan 7 10:54: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 KAA22453 for ; Fri, 7 Jan 2005 10:54: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 j07FmUgi028138; Fri, 7 Jan 2005 07:48: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 j07FmUii028137; Fri, 7 Jan 2005 07:48: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 j07FmTdE028113; Fri, 7 Jan 2005 07:48: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 j07FmVdt014351; Fri, 7 Jan 2005 08:48:31 -0700 (MST) Received: from xpa-fe1 (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 <0I9Y0066NEKVBP@edgemail1.Central.Sun.COM>; Fri, 07 Jan 2005 08:48:31 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9Y00HNNEKU94@mail.sun.net>; Fri, 07 Jan 2005 08:48:31 -0700 (MST) Date: Fri, 07 Jan 2005 07:48:25 -0800 From: Tim Bray Subject: Re: Atom extensibility In-reply-to: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> To: Henry Story Cc: "'Atom WG'" , Paul Hoffman / IMC Message-id: <90FDC7B8-60C3-11D9-A2C8-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=ISO-8859-1; format=flowed References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j07FmTdE028117 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Jan 7, 2005, at 6:54 AM, Henry Story wrote: > The question is exactly how should the interesting discovery that an > Atom document is an RDF document [Ø] be used to fulfill the charter > requirements on extensibility? > Clearly it could completely underpin the extensibility framework, and > so allow the Atom charter to be successfully fulfilled. I think that the charter requirements on extensibility will be filled adequately with PaceExtendingAtom. I think they would be filled still better by adopting PaceMustUnderstandElement, but apparently others are unconvinced. Extensibility via a mapping to RDF seems to me to add a lot of complexity (most people have never bothered to learn graph theory) without any real benefit. -Tim From owner-atom-syntax@mail.imc.org Fri Jan 7 13:29: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 NAA03652 for ; Fri, 7 Jan 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 j07IC5sh069197; Fri, 7 Jan 2005 10:12: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 j07IC5o2069196; Fri, 7 Jan 2005 10:12:05 -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 j07IC4JF069188 for ; Fri, 7 Jan 2005 10:12:05 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so629269rnz for ; Fri, 07 Jan 2005 10:12: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=RQw39CSopVk43UFN/rI5lvt7UfeM5BOfnrjt0v2cmTRxwtzz55aCn1TOOVVmbaAH3ndszctkqaIoap8ljuODNSowmbZSbwy3GMMMAxRzBi/ZjNvfURMiS8Hkb7bo9ANrV7Br6JjOWCZ4ioMAxJGSnd7M+JpEfPpUtdkJicadH/M= Received: by 10.38.206.12 with SMTP id d12mr389766rng; Fri, 07 Jan 2005 10:12:08 -0800 (PST) Received: by 10.38.179.58 with HTTP; Fri, 7 Jan 2005 10:12:08 -0800 (PST) Message-ID: <1f2ed5cd050107101261b8a1d5@mail.gmail.com> Date: Fri, 7 Jan 2005 19:12:08 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: RSS extensibility Cc: atom-syntax@imc.org In-Reply-To: <0EB0A912-60C3-11D9-A2C8-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd05010705487956cbbf@mail.gmail.com> <0EB0A912-60C3-11D9-A2C8-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 07 Jan 2005 07:44:46 -0800, Tim Bray wrote: > On Jan 7, 2005, at 5:48 AM, Danny Ayers wrote: > > > > xmlns:prism="http://prismstandard.org/namespaces/1.2/basic/"> > > > > 2005-02-15 > > ... > > > > > > > > [[ > > embargoDate > > Earliest date (potentially including time) the resource may be used > > according to the rights agreement, or clause in the rights agreement. > > ]] > > > > So the human meaning of an 'embargoDate' element is reasonably clear. > > The problem is that with RSS 2.0's approach to extensibility, there is > > no relationship defined between this element and any part of the feed > > data. Ok, it's an embargo date. But the embargo date of what? > > The embargo date of the entry. This seems painfully obvious, and any > other reading would be willfully contrary. To you maybe, but how are applications to know that? Either software understands > what embargoDate means or it doesn't, and if it does, well then, it'll > embargo the entry, and if not, not. But it isn't that black and white. The software may understand that embargoDate is a property of the entry, without knowing anything about embargos. This is useful information, especially if you wish you want to merge data from disparate sources (and possibly republish), an scenario that's becoming more widespread in syndication. > I have not seen any evidence that these RDF incantations have any > relation to the needs of implementors. -Tim Now that really is wilful contrariness. I made a comparison between the approach to extensibility taken by RSS 1.0 and RSS 2.0. I suggested that RSS 1.0 had advantages that would benefit Atom. I also suggested that RDF wasn't needed for Atom to enjoy those advantages. Where are the incantations? I can find more evidence of the utility of RSS 1.0's approach if necessary, but I would have hoped that contributors to this project will have done some research into what application implementors are doing with RSS 1.0. Quick quote: [[ As a science publisher, however, we are minded to continue to produce RSS 1.0 for the immediate future, since it meets all our current needs, while monitoring the Atom development to see what end utility it might afford. Our current view is that Atom does not provide the necessary level of metadata extensibility and interoperability that we are able to achieve with RSS 1.0. ]] http://dlib.anu.edu.au/dlib/december04/hammond/12hammond.html Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Jan 7 13:56: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 NAA04845 for ; Fri, 7 Jan 2005 13:56: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 j07IjeoG075760; Fri, 7 Jan 2005 10:45: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 j07IjehC075759; Fri, 7 Jan 2005 10:45:40 -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 j07Ijd73075739 for ; Fri, 7 Jan 2005 10:45:40 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so630912rnz for ; Fri, 07 Jan 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=uBANrGJg8gYeC6rAakFhjaPtlxk/yr22epUvKGUMSbUlOGCJy0UcyO9hLtGNW1/P9B38yttaumzeSWDIBe9AZm3flsEFC+urH9/rCwdu/VO7qx1M7azizZlS20dfPHpqaDhkg6aso2PYhwFUNPjPeBYpKvskrJoLixKkCy36Yuk= Received: by 10.38.8.38 with SMTP id 38mr208579rnh; Fri, 07 Jan 2005 10:45:43 -0800 (PST) Received: by 10.38.179.58 with HTTP; Fri, 7 Jan 2005 10:45:43 -0800 (PST) Message-ID: <1f2ed5cd05010710452f652e3@mail.gmail.com> Date: Fri, 7 Jan 2005 19:45:43 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: Atom extensibility Cc: Henry Story , Atom WG , Paul Hoffman / IMC In-Reply-To: <90FDC7B8-60C3-11D9-A2C8-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <90FDC7B8-60C3-11D9-A2C8-000A95A51C9E@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j07Ije73075747 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 07 Jan 2005 07:48:25 -0800, Tim Bray wrote: > > On Jan 7, 2005, at 6:54 AM, Henry Story wrote: > > > The question is exactly how should the interesting discovery that an > > Atom document is an RDF document [Ø] be used to fulfill the charter > > requirements on extensibility? > > Clearly it could completely underpin the extensibility framework, and > > so allow the Atom charter to be successfully fulfilled. > > I think that the charter requirements on extensibility will be filled > adequately with PaceExtendingAtom. I think they would be filled still > better by adopting PaceMustUnderstandElement, but apparently others are > unconvinced. The charter requirements could be fulfilled in any number of ways, not all of them useful. I think PaceMustUnderstandElement may well be a good idea. PaceExtendingAtom does shield Atom core data from unwanted interference from foreign elements, but that shielding can still happen alongside partial understanding. Extensibility via a mapping to RDF seems to me to add a > lot of complexity (most people have never bothered to learn graph > theory) without any real benefit. -Tim There are feeds in RDF from the blogs of millions of users that haven't learnt graph theory. Given Henry's proposal, the person that uses RSS 2.0 today would notice no additional complexity. The only people that would need to know a little about RDF would be those that wish to develop extensions. All they would really need to know are a few syntax rules. On the other hand, if extension markup can appear anywhere (as in PaceExtendingAtom) application developers will have to deal with the complexity of handling every extension completely on a completely case-by-case basis. Extensibility via a mapping to RDF will happen, whether it appears in the specifications or not. Whether it can be done consistently across extensions will depend on how consistently those extensions are expressed in Atom. I personally would prefer an RDF-oriented approach in the core, as I think RSS 1.0 demonstrates its utility. But if there is obtuse antagonism towards RDF then a reasonable compromise would seem to be some having some simple structural syntax constraints that extensions should follow. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Jan 7 14:30: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 OAA06558 for ; Fri, 7 Jan 2005 14:30: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 j07JLNMC085530; Fri, 7 Jan 2005 11:21: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 j07JLNBW085529; Fri, 7 Jan 2005 11:21:23 -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 j07JLKXR085519; Fri, 7 Jan 2005 11:21:21 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <90FDC7B8-60C3-11D9-A2C8-000A95A51C9E@sun.com> References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <90FDC7B8-60C3-11D9-A2C8-000A95A51C9E@sun.com> Date: Fri, 7 Jan 2005 11:17:07 -0800 To: Tim Bray , Henry Story From: Paul Hoffman / IMC Subject: Re: Atom extensibility 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 7:48 AM -0800 1/7/05, Tim Bray wrote: >I think that the charter requirements on extensibility will be >filled adequately with PaceExtendingAtom. I think they would be >filled still better by adopting PaceMustUnderstandElement, but >apparently others are unconvinced. Extensibility via a mapping to >RDF seems to me to add a lot of complexity (most people have never >bothered to learn graph theory) without any real benefit. -Tim Wearing my co-chair hat, I fully agree with Tim. We are already fulfilling our charter requirements without defining a mapping to RDF. A document that shows another way to do extensibility through RDF is fine, but it is not required by the charter (nor by the vast majority of active posters on the list). --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri Jan 7 14:36: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 OAA07606 for ; Fri, 7 Jan 2005 14:36: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 j07JTvh6086563; Fri, 7 Jan 2005 11:29: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 j07JTvCY086562; Fri, 7 Jan 2005 11:29: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.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j07JTuPV086555 for ; Fri, 7 Jan 2005 11:29:56 -0800 (PST) (envelope-from lavandowska@gmail.com) Received: by wproxy.gmail.com with SMTP id 40so530538wri for ; Fri, 07 Jan 2005 11:29:55 -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=esMYIlIqzgZKkKOoxKC7qB/m5HuKMm3506DfAS/Fy406m0CmwuVQtyEq7RWex5hpQGu+CiClkyHpotC5C9So+wlBlAHncSyEZZ/0kCg3TN7bTWGUPuUB1g8Fkt5/uAmRFet+YOMo61Qwdehgot0BtG+9M4TWL812zH0SGcS+i/g= Received: by 10.54.17.29 with SMTP id 29mr85638wrq; Fri, 07 Jan 2005 11:29:55 -0800 (PST) Received: by 10.54.59.5 with HTTP; Fri, 7 Jan 2005 11:29:54 -0800 (PST) Message-ID: <96d7d77c05010711297eb23404@mail.gmail.com> Date: Fri, 7 Jan 2005 13:29:54 -0600 From: Lance Lavandowska Reply-To: Lance Lavandowska To: atom-syntax@imc.org Subject: Re: Atom extensibility In-Reply-To: <1f2ed5cd05010710452f652e3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <90FDC7B8-60C3-11D9-A2C8-000A95A51C9E@sun.com> <1f2ed5cd05010710452f652e3@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 7 Jan 2005 19:45:43 +0100, Danny Ayers wrote: > > Given Henry's proposal, the person that uses RSS 2.0 today would > notice no additional complexity. The only people that would need to > know a little about RDF would be those that wish to develop > extensions. All they would really need to know are a few syntax rules. As a nobody who still cannot quite grasp RDF, I really like Henry's proposal. Danny can have his RDF cake, and I can eat it too. Lance From owner-atom-syntax@mail.imc.org Fri Jan 7 14:37: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 OAA07672 for ; Fri, 7 Jan 2005 14: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 j07JLPHK085537; Fri, 7 Jan 2005 11:21: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 j07JLPFN085536; Fri, 7 Jan 2005 11:21: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 j07JLKXT085519; Fri, 7 Jan 2005 11:21:22 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 7 Jan 2005 11:21:22 -0800 To: Eric Scheid , Atom Syntax From: Paul Hoffman / IMC Subject: Re: The Atom Format end-game 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 6:31 PM +1100 1/7/05, Eric Scheid wrote: >Aside from focusing on the publishing protocol, which is well due, what else >happens after we finalise the format spec? > >Specifically, what are the IETF hoops that need to be jumped through, and >what periods of diligence/comment are mandated? Or will the document we >settle on at such-n-such date be the one we are completely stuck with for >quite a while until we get around to working on Atom 2.0? If we want to >revise 1.0, do we need to formally establish a new WG through the IETF, or >just carry on from here. The process is that we (the WG) say "this Internet Draft is done". The chairs then communicate this to our AD. He looks it over and either asks for changes based on his read-through, or he starts an IETF-wide two-week last call. After that IETF-wide last call, either he asks us to make changes, or he takes it to the IESG. After their review, they either ask us for revisions or they pass it to the RFC Editor for publication. Approximately. >What I'd like to see is one last version of the spec released for trial >deployment (0.9?), in the same sense that 0.3 is out there in the wild, so >that we can see all the mistakes that people make interpreting the spec, >what things work and don't work ... and we can then do a quick spackle and >buff before announcing 1.0. Or is it a trivial matter to revisit the spec in >(say) 3-6 months and quickly burp the baby to get v1.1? We can revisit whenever we want to. Some WGs do revisions starting immediately after the RFC is published, others wait a year or two. That is completely up to us, and there are no IETF impediments to moving quickly or slowly on revisions. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri Jan 7 14:40: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 OAA07889 for ; Fri, 7 Jan 2005 14:40: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 j07JWYET086894; Fri, 7 Jan 2005 11:32: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 j07JWYfN086893; Fri, 7 Jan 2005 11:32:34 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j07JWWTq086878 for ; Fri, 7 Jan 2005 11:32:33 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta03-winn.mailhost.ntl.com ([212.250.162.8]) by mta13-winn.mailhost.ntl.com with ESMTP id <20050107193213.ZVOM10495.mta13-winn.mailhost.ntl.com@aamta03-winn.mailhost.ntl.com>; Fri, 7 Jan 2005 19:32:13 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta03-winn.mailhost.ntl.com with ESMTP id <20050107193213.VWPG9818.aamta03-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Fri, 7 Jan 2005 19:32:13 +0000 Date: Fri, 7 Jan 2005 19:32:10 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <968979563.20050107193210@djpowell.net> To: Henry Story CC: Antone Roundy , "'Atom WG'" Subject: Re: To RDF or not to RDF, that is the (perennial) question In-Reply-To: <7DE36F95-600A-11D9-8C3F-000A95D9FA7A@bblfish.net> References: <7DE36F95-600A-11D9-8C3F-000A95D9FA7A@bblfish.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 Thursday, January 6, 2005, 5:43:36 PM, you wrote: > [1] http://www.imc.org/atom-syntax/mail-archive/msg11850.html > I later found ways around most (all?) of the problems I had > identified in that mail on the atom-owl mailing list. Just a minor point on that email: > - an owl file could specify that atom:href is a subproperty of rdf:resource, and so > alloow us to replace rdf:resource with atom:href "rdf:resource" is a syntactic element of RDF/XML, not anything that appears in an RDF model, so I wouldn't have thought that an OWL file could do syntactic tricks like this? -- Dave From owner-atom-syntax@mail.imc.org Fri Jan 7 14: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 OAA11635 for ; Fri, 7 Jan 2005 14: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 j07Jol8J093792; Fri, 7 Jan 2005 11: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 j07JolFd093787; Fri, 7 Jan 2005 11:50:47 -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 j07JokT9093759 for ; Fri, 7 Jan 2005 11:50:46 -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 j07JooVu022294 for ; Fri, 7 Jan 2005 12:50:50 -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 <0I9Y005ZSPSPXY@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 07 Jan 2005 12:50:50 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9Y0056JPSPUN@mail.sun.net> for atom-syntax@imc.org; Fri, 07 Jan 2005 12:50:49 -0700 (MST) Date: Fri, 07 Jan 2005 11:50:49 -0800 From: Tim Bray Subject: Re: RSS extensibility In-reply-to: <1f2ed5cd050107101261b8a1d5@mail.gmail.com> To: Danny Ayers Cc: atom-syntax@imc.org Message-id: <6DE42CD2-60E5-11D9-A2C8-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: <1f2ed5cd05010705487956cbbf@mail.gmail.com> <0EB0A912-60C3-11D9-A2C8-000A95A51C9E@sun.com> <1f2ed5cd050107101261b8a1d5@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 7, 2005, at 10:12 AM, Danny Ayers wrote: >>> >>> 2005-02-15 >>> ... >>> ... >>> Ok, it's an embargo date. But the embargo date of what? >> >> The embargo date of the entry. This seems painfully obvious, and any >> other reading would be willfully contrary. > > To you maybe, but how are applications to know that? I think we must live on different planets. If I propose an extension, e.g. embargoDate, and I want anyone to use it, then I'm going to have to specify how it works. E.g. " can appear as a child of and it gives the embargo date for the entry..." Software which wants to *operate* on this is going to have to know these semantics. Software which does not know the semantics can do exactly nothing useful, aside from either ignore it (typical for clients) or copy it through (typical for middleware). I'm sorry, the assertion that it's not clear what's going on the example above is just incomprehensible to me. -Tim From owner-atom-syntax@mail.imc.org Fri Jan 7 14: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 OAA12265 for ; Fri, 7 Jan 2005 14: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 j07JmbaN088871; Fri, 7 Jan 2005 11:48: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 j07Jmas0088832; Fri, 7 Jan 2005 11:48: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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j07JmZCA088534 for ; Fri, 7 Jan 2005 11:48:36 -0800 (PST) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so527030wri for ; Fri, 07 Jan 2005 11:48:34 -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=Sza4NLHArficoMtkvQDpgp+pxJQykU5ZcxiJZGlUpuz3NGW+lGND10Fr9DnZvYlmzeeHPV5XtT9X129iZ5Hb9bO+88ARysaz0AMHaNG60vPTJZzU/cZnFgz5npCQf9mW+e3qgKVn1TMy6Q2uAvRTC7ypWBexkytVFu6p+PpywsA= Received: by 10.54.18.9 with SMTP id 9mr74674wrr; Fri, 07 Jan 2005 11:48:34 -0800 (PST) Received: by 10.54.18.53 with HTTP; Fri, 7 Jan 2005 11:48:34 -0800 (PST) Message-ID: <540e3732050107114849e6886b@mail.gmail.com> Date: Fri, 7 Jan 2005 13:48:34 -0600 From: "Roger B." Reply-To: "Roger B." To: atom-syntax@imc.org Subject: Re: Posted PaceEnclosuresAndPix In-Reply-To: <54CD5E58-5F76-11D9-A316-000D93C9CE82@sdf1.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <96d7d77c0501051428125ae064@mail.gmail.com> <758E5557-5F6C-11D9-A2C8-000A95A51C9E@sun.com> <54CD5E58-5F76-11D9-A316-000D93C9CE82@sdf1.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > In > addition to being cumbersome, there is no good way to show that the > photos all go together. Ray: There are several, IMO. (1) Put them all in the same rss:category. (2) Use ENT and assign them all at least one common topic. (3) Put them in a distict feed. At least one of those is fairly trivial for just about every app out there, and all of them are better than treating a single item as a content dump, IMO. -- Roger Benningfield blog: http://admin.support.journurl.com/ From owner-atom-syntax@mail.imc.org Fri Jan 7 15:23: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 PAA18404 for ; Fri, 7 Jan 2005 15:23: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 j07KBGJw024072; Fri, 7 Jan 2005 12:11: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 j07KBGig024062; Fri, 7 Jan 2005 12:11: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 j07KBENv024019 for ; Fri, 7 Jan 2005 12:11:14 -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 j07KBIVu005088 for ; Fri, 7 Jan 2005 13:11:18 -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 <0I9Y003UUQQUFU@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 07 Jan 2005 13:11:18 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9Y005DPQQTUN@mail.sun.net> for atom-syntax@imc.org; Fri, 07 Jan 2005 13:11:18 -0700 (MST) Date: Fri, 07 Jan 2005 12:11:17 -0800 From: Tim Bray Subject: Enclosure count To: "'Atom WG'" Message-id: <49ECE2C1-60E8-11D9-A2C8-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 Based on comments here, I revised PaceEnclosuresAndPix to lose the one-enclosure-per-entry restriction. -Tim From owner-atom-syntax@mail.imc.org Fri Jan 7 15:46: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 PAA22991 for ; Fri, 7 Jan 2005 15:46: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 j07KcEeO059904; Fri, 7 Jan 2005 12:38: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 j07KcEeU059903; Fri, 7 Jan 2005 12:38: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.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j07KcDZc059846 for ; Fri, 7 Jan 2005 12:38:13 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so636623rnz for ; Fri, 07 Jan 2005 12:38:14 -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=mw9qkfZR44qc00/Tz+SZ9zFrvtUSfdULdBpiyOx/mTcoQ4kD7LyLLDBkWVKeS7oOYnVWjybAtqD87WOhprXysCFhYshb6PEIui6+1VSd9k3WnMxU2xFv0nXpwkOA9AvhEcB18CdhOmyJR1IWHn7kkI3Jm9DCkj2FYUNIQVFb0GU= Received: by 10.38.8.38 with SMTP id 38mr248690rnh; Fri, 07 Jan 2005 12:38:13 -0800 (PST) Received: by 10.38.179.58 with HTTP; Fri, 7 Jan 2005 12:38:13 -0800 (PST) Message-ID: <1f2ed5cd0501071238360cb4ad@mail.gmail.com> Date: Fri, 7 Jan 2005 21:38:13 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Lance Lavandowska Subject: Re: Atom extensibility Cc: atom-syntax@imc.org In-Reply-To: <96d7d77c05010711297eb23404@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <90FDC7B8-60C3-11D9-A2C8-000A95A51C9E@sun.com> <1f2ed5cd05010710452f652e3@mail.gmail.com> <96d7d77c05010711297eb23404@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 7 Jan 2005 13:29:54 -0600, Lance Lavandowska wrote: > > On Fri, 7 Jan 2005 19:45:43 +0100, Danny Ayers wrote: > > > > Given Henry's proposal, the person that uses RSS 2.0 today would > > notice no additional complexity. The only people that would need to > > know a little about RDF would be those that wish to develop > > extensions. All they would really need to know are a few syntax rules. > > As a nobody who still cannot quite grasp RDF, I really like Henry's > proposal. Danny can have his RDF cake, and I can eat it too. Mmmm...cake.... http://semtext.org/2004-02/slides/img4.html From owner-atom-syntax@mail.imc.org Fri Jan 7 15:46: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 PAA23115 for ; Fri, 7 Jan 2005 15:46: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 j07KWoHN051265; Fri, 7 Jan 2005 12:32: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 j07KWofN051263; Fri, 7 Jan 2005 12:32:50 -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 j07KWnkk051143 for ; Fri, 7 Jan 2005 12:32:50 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so636383rnz for ; Fri, 07 Jan 2005 12: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:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=bJaXlOqLtH5GvLM63gtiUU/UBrel11v0uB1YvEgXAWnKj4Z1X4jDWRNEE2VbyxyJPBXuGTQeKQcxlc/5w+4N+S11Ndra5Y4CMyxbnQKkSpvO6OYbTRDgBRwfscv7WIbcw+fODyLu7YLKk5ogeD90rOK73XYF3mshuPWU/Rz+9eA= Received: by 10.38.8.13 with SMTP id 13mr431100rnh; Fri, 07 Jan 2005 12:32:48 -0800 (PST) Received: by 10.38.179.58 with HTTP; Fri, 7 Jan 2005 12:32:48 -0800 (PST) Message-ID: <1f2ed5cd050107123223927528@mail.gmail.com> Date: Fri, 7 Jan 2005 21:32:48 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: RSS extensibility Cc: atom-syntax@imc.org In-Reply-To: <6DE42CD2-60E5-11D9-A2C8-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd05010705487956cbbf@mail.gmail.com> <0EB0A912-60C3-11D9-A2C8-000A95A51C9E@sun.com> <1f2ed5cd050107101261b8a1d5@mail.gmail.com> <6DE42CD2-60E5-11D9-A2C8-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 07 Jan 2005 11:50:49 -0800, Tim Bray wrote: > On Jan 7, 2005, at 10:12 AM, Danny Ayers wrote: > > >>> > >>> 2005-02-15 > >>> ... > >>> > ... > >>> Ok, it's an embargo date. But the embargo date of what? > >> > >> The embargo date of the entry. This seems painfully obvious, and any > >> other reading would be willfully contrary. > > > > To you maybe, but how are applications to know that? > > I think we must live on different planets. All I'm suggesting here is making the part you called "painfully obvious" explicit. If I propose an extension, > e.g. embargoDate, and I want anyone to use it, then I'm going to have > to specify how it works. E.g. " can appear as a > child of and it gives the embargo date for the entry..." True. > Software which wants to *operate* on this is going to have to know > these semantics. Not entirely true. Software which does not know the semantics can do > exactly nothing useful, aside from either ignore it (typical for > clients) or copy it through (typical for middleware). The software may not know all the semantics and still do something useful. > I'm sorry, the assertion that it's not clear what's going on the > example above is just incomprehensible to me. -Tim In your example you are giving a specific meaning to this specific parent-child relationship within the Atom format. You are describing a relationship between entities - the entry is one entity, the date another, and the relationship is that the second is the embargoDate of the first. Ok, now what if the Atom spec said that all child elements of are to be considered to be characteristics of that entry, with the value of those characteristics being given by the content of the child. This would mean that in your specification you'd only have to state the specific meaning of "embargoDate", not how the structure should be interpreted. The entity-relationship model would be consistently mapped from the syntax across all extensions. Like having a light schema to work from. One less job for you, the extension developer. It's also one less job (per extension) for every single developer that wishes to support extensions. This particular part of their code would only have to be written once. It also enable consumers of this data to answer questions like "what is this entity related to?" without knowing the details of specific extensions. If those are other resources with that can potentially be very useful in a place like the Web. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Jan 7 15:55: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 PAA24490 for ; Fri, 7 Jan 2005 15:55: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 j07Kh18M067174; Fri, 7 Jan 2005 12:43: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 j07Kh1Oi067172; Fri, 7 Jan 2005 12:43:01 -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 j07Kh0V6067026 for ; Fri, 7 Jan 2005 12:43:00 -0800 (PST) (envelope-from kier@sdf1.net) Received: from [10.0.22.54] (unknown [209.167.45.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.sdf1.net (Postfix) with ESMTP id AF47E354D9; Fri, 7 Jan 2005 15:43:03 -0500 (EST) In-Reply-To: <49ECE2C1-60E8-11D9-A2C8-000A95A51C9E@sun.com> References: <49ECE2C1-60E8-11D9-A2C8-000A95A51C9E@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-6-121843171" Message-Id: Cc: "'Atom WG'" From: Ray Slakinski Subject: Re: Enclosure count Date: Fri, 7 Jan 2005 15:42:58 -0500 To: Tim Bray Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-6-121843171 Content-Type: multipart/alternative; boundary=Apple-Mail-5-121843159 --Apple-Mail-5-121843159 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Glad to hear it :) btw can you make one other small change to the doc -- Lance said to change size to content-length and it sounded like you agreed. I think content-length makes more sense as well. >> 3) On the 'size' attribute. 'size', 'length' and 'content-length' >> have been proposed ('length' is in the PaceLinkRelated [2]. I prefer >> (content-)length, as size appears ambiguous. > > Oops, right. -Tim [-----] Ray Slakinski Fingerprint: C8AD 4847 2DA8 3469 079D 13F9 135D F0CF 1CFC FD03 Blog: http://ddll.sdf1.net Adolescence, n.: The stage between puberty and adultery. On 7-Jan-05, at 3:11 PM, Tim Bray wrote: > > Based on comments here, I revised PaceEnclosuresAndPix to lose the > one-enclosure-per-entry restriction. -Tim > --Apple-Mail-5-121843159 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Glad to hear it :) btw can you make one other small change to the doc -- Lance said to change size to content-length and it sounded like you agreed. I think content-length makes more sense as well. 3) On the 'size' attribute. 'size', 'length' and 'content-length' have been proposed ('length' is in the PaceLinkRelated [2]. I prefer (content-)length, as size appears ambiguous. Oops, right. -Tim0000,6362,1211 [-----] Ray Slakinski Fingerprint: C8AD 4847 2DA8 3469 079D 13F9 135D F0CF 1CFC FD03 Blog: http://ddll.sdf1.net Adolescence, n.: The stage between puberty and adultery. On 7-Jan-05, at 3:11 PM, Tim Bray wrote: Based on comments here, I revised PaceEnclosuresAndPix to lose the one-enclosure-per-entry restriction. -Tim --Apple-Mail-5-121843159-- --Apple-Mail-6-121843171 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkHe9FIACgkQE13wzxz8/QPQwgCcCvF9+HLXVbox4d8X+j6eaXlP k5YAnjsyammqRipRNueLIrLmUlwcj/M9 =adJB -----END PGP SIGNATURE----- --Apple-Mail-6-121843171-- From owner-atom-syntax@mail.imc.org Fri Jan 7 15:59: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 PAA25618 for ; Fri, 7 Jan 2005 15:59: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 j07Kjhdb071313; Fri, 7 Jan 2005 12: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 j07KjhFB071312; Fri, 7 Jan 2005 12:45:43 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j07KjfIK071139 for ; Fri, 7 Jan 2005 12:45:42 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta01-winn.mailhost.ntl.com ([212.250.162.8]) by mta13-winn.mailhost.ntl.com with ESMTP id <20050107204540.JMEC10495.mta13-winn.mailhost.ntl.com@aamta01-winn.mailhost.ntl.com>; Fri, 7 Jan 2005 20:45:40 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta01-winn.mailhost.ntl.com with ESMTP id <20050107204540.ZRLG15415.aamta01-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Fri, 7 Jan 2005 20:45:40 +0000 Date: Fri, 7 Jan 2005 20:45:37 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <1546484102.20050107204537@djpowell.net> To: Tim Bray CC: Danny Ayers , atom-syntax@imc.org Subject: Re: RSS extensibility In-Reply-To: <6DE42CD2-60E5-11D9-A2C8-000A95A51C9E@sun.com> References: <1f2ed5cd05010705487956cbbf@mail.gmail.com> <0EB0A912-60C3-11D9-A2C8-000A95A51C9E@sun.com> <1f2ed5cd050107101261b8a1d5@mail.gmail.com> <6DE42CD2-60E5-11D9-A2C8-000A95A51C9E@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 Friday, January 7, 2005, 7:50:49 PM, you wrote: > I think we must live on different planets. If I propose an extension, > e.g. embargoDate, and I want anyone to use it, then I'm going to have > to specify how it works. E.g. " can appear as a > child of and it gives the embargo date for the entry..." > Software which wants to *operate* on this is going to have to know > these semantics. Software which does not know the semantics can do > exactly nothing useful, aside from either ignore it (typical for > clients) or copy it through (typical for middleware). > I'm sorry, the assertion that it's not clear what's going on the > example above is just incomprehensible to me. -Tim A couple more examples: An entry has an ex:digitalSignature property. This is intended to be a digital signature of that exact instance of an atom entry. The entry is annotated using an atom:origin element, and republished by a Planet*-type site. Because the subject of the property wasn't communicated explicitly, then this property has been republished resulting in an incorrect signature. If there was a way to tell whether a property applied to an entry directly, then it would be safe for the republisher to republish all properties of the entry, even if they were extensions whose meaning wasn't known to the republisher. Another example might be a property such as ex:rating, intended to provide slashdot-style ratings specific to the community of readers of that feed. If those entries are republished, then the original ratings shouldn't be republished in the aggregate feed. HTTP has the same extensibility problems. Of 4 different types of header, only entity headers can be extended unless you wait for HTTP/2.0. [1] At least HTTP makes this limitation clear. Whether or not we involve RDF, we probably need to be clear about what properties implicitly apply to; in the least ambitious case, by doing what HTTP does: "all extensions apply directly to the content, properties of entities such as the physical representation of the content cannot be described by extensions". If we decide that extensions such as the two above are not allowed in Atom, that is better than saying nothing. [1] RFC 2616; sections 4.5, 5.3, 6.2, and 7.1 -- Dave From owner-atom-syntax@mail.imc.org Fri Jan 7 16:09: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 QAA28508 for ; Fri, 7 Jan 2005 16:09: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 j07KutHC085942; Fri, 7 Jan 2005 12:56: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 j07KutuM085938; Fri, 7 Jan 2005 12:56:55 -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 j07KutOv085889; Fri, 7 Jan 2005 12:56:55 -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 1Cn1A2-0002Ge-NO; Fri, 07 Jan 2005 20:56:42 +0000 Message-ID: <41DEF794.5050707@franklinmint.fm> Date: Fri, 07 Jan 2005 15:56:52 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Story CC: "'Atom WG'" , Paul Hoffman / IMC Subject: Re: Atom extensibility References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> In-Reply-To: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.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 Henry Story wrote: > The question is exactly how should the interesting discovery that an > Atom document is an RDF document [Ø] be used to fulfill the charter > requirements on extensibility? Have you figured out a way to deal with this: > > > So perhaps we can open this thread as a place to post ideas on the topic. I think the debate is pretty much settled for client GUI software. RDF doesn't help a bit. A more interesting situation is a server receiving Atom entries to publish. For the purposes of discussion, let's say the server trusts the client. It gets a POST with a fairly average atom entry, but there are extensions in funny places. Like most people, the server stores standard fields in a relational database, so there are columns for title, summary, etc. in a table called something like "journal_entries". It would be fairly easy to store immediate children of entry in an "unknown_xml" field, and pass them through, but what about the other extensions? Using an RDF store might make this problem a lot easier, but I don't forsee a mass migration in that direction happening this year or next. POST ... My cat me adfadf I took my cat on vacation It was really fun adfadsfa ... So, what's the algorithm and storage strategy that will allow maximum extensibility but not require servers to re-architect? Robert Sayre From owner-atom-syntax@mail.imc.org Fri Jan 7 16:10: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 QAA28540 for ; Fri, 7 Jan 2005 16:10: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 j07L0iHv091091; Fri, 7 Jan 2005 13:00: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 j07L0ius091090; Fri, 7 Jan 2005 13:00: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.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j07L0hx7090999 for ; Fri, 7 Jan 2005 13:00:44 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so637779rnz for ; Fri, 07 Jan 2005 13:00: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=uU/XbzIDk76tj7onmsWUvY9FsUpApJgKVI3CJ6cU5NO37cs3EdXTpO1FcOLb7/05dtOsbloPTVhtbm2nwSWsSG38qKbXDXIUPEgN4iGhPlq2QKAgJc/lZ+HuQut80mWLB74u54b9syvFwa8we7Dq4awJG0xZXJNewK/CHHI1cZg= Received: by 10.38.8.13 with SMTP id 13mr440369rnh; Fri, 07 Jan 2005 13:00:41 -0800 (PST) Received: by 10.38.179.58 with HTTP; Fri, 7 Jan 2005 13:00:41 -0800 (PST) Message-ID: <1f2ed5cd0501071300bfd5504@mail.gmail.com> Date: Fri, 7 Jan 2005 22:00:41 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: Atom extensibility Cc: Henry Story , Atom WG , Paul Hoffman / IMC In-Reply-To: <90FDC7B8-60C3-11D9-A2C8-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <90FDC7B8-60C3-11D9-A2C8-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 07 Jan 2005 07:48:25 -0800, Tim Bray wrote: Extensibility via a mapping to RDF seems to me to add a > lot of complexity (most people have never bothered to learn graph > theory) without any real benefit. -Tim btw, here's quite a good RDF tutorial which doesn't involve graph theory: http://www.xml.com/pub/a/2001/01/24/rdf.html -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Jan 7 16:13: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 QAA28980 for ; Fri, 7 Jan 2005 16:13: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 j07Kxpjt089845; Fri, 7 Jan 2005 12:59: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 j07Kxps0089842; Fri, 7 Jan 2005 12:59:51 -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 j07KxogJ089682 for ; Fri, 7 Jan 2005 12:59:50 -0800 (PST) (envelope-from djacobs@gmail.com) Received: by rproxy.gmail.com with SMTP id r35so401879rna for ; Fri, 07 Jan 2005 12:59: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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=gH6sXGza/KUqTtPZW3zb981TbNJMq8j8Ue4Uyg7l5onTaHaPh3WvP5l3TQjFNP1gCwUEAoYRMdYa39AdP9mlG65ssFyLPugRXy82WEySF+dj5Ptyc5giCx/SKeqAlQ0GiZoZtOkMvpFTjAi1UzzxYg8V4DgBjpvIwT3+dgHa5Lk= Received: by 10.38.10.15 with SMTP id 15mr266422rnj; Fri, 07 Jan 2005 12:59:49 -0800 (PST) Received: by 10.38.161.22 with HTTP; Fri, 7 Jan 2005 12:59:49 -0800 (PST) Message-ID: <466cecc905010712597c809719@mail.gmail.com> Date: Fri, 7 Jan 2005 15:59:49 -0500 From: David Jacobs Reply-To: David Jacobs To: Tim Bray Subject: Re: Enclosure count Cc: Atom WG In-Reply-To: <49ECE2C1-60E8-11D9-A2C8-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <49ECE2C1-60E8-11D9-A2C8-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit RSS 2.0 DOES have a one enclosure per entry restriction, so we're breaking RSS2 compatibility. Why wouldn't multiple enclosures be multiple posts? From owner-atom-syntax@mail.imc.org Fri Jan 7 16:17: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 QAA29196 for ; Fri, 7 Jan 2005 16:17: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 j07L8Tor099982; Fri, 7 Jan 2005 13:08: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 j07L8T87099980; Fri, 7 Jan 2005 13:08:29 -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 j07L8SCs099964 for ; Fri, 7 Jan 2005 13:08:28 -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 j07L8Xdt021436 for ; Fri, 7 Jan 2005 14:08:33 -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 <0I9Y00340TE8FU@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 07 Jan 2005 14:08:33 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9Y00553TDUUN@mail.sun.net> for atom-syntax@imc.org; Fri, 07 Jan 2005 14:08:18 -0700 (MST) Date: Fri, 07 Jan 2005 13:08:18 -0800 From: Tim Bray Subject: Re: Enclosure count In-reply-to: To: Ray Slakinski Cc: "'Atom WG'" Message-id: <40D78188-60F0-11D9-A2C8-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: <49ECE2C1-60E8-11D9-A2C8-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 7, 2005, at 12:42 PM, Ray Slakinski wrote: > Glad to hear it :) btw can you make one other small change to the doc > -- Lance said to change size to content-length and it sounded like you > agreed. I think content-length makes more sense as well. Oops, right. I used "length", same as RSS2. -Tim From owner-atom-syntax@mail.imc.org Fri Jan 7 16:31: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 QAA00761 for ; Fri, 7 Jan 2005 16:31: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 j07LMGA9012938; Fri, 7 Jan 2005 13:22: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 j07LMGFE012937; Fri, 7 Jan 2005 13:22:16 -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 j07LMGGj012276 for ; Fri, 7 Jan 2005 13:22:16 -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 <2005010721215001200pi8jne>; Fri, 7 Jan 2005 21:21:51 +0000 Date: Fri, 7 Jan 2005 14:21:49 -0700 Subject: Re: RSS extensibility 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: <1f2ed5cd050107123223927528@mail.gmail.com> Message-Id: <24B82B2A-60F2-11D9-8D42-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, January 7, 2005, at 01:32 PM, Danny Ayers wrote: >> If I propose an extension, >> e.g. embargoDate, and I want anyone to use it, then I'm going to have >> to specify how it works. E.g. " can appear as a >> child of and it gives the embargo date for the entry..." ... >> Software which wants to *operate* on this is going to have to know >> these semantics. >> >> Software which does not know the semantics can do >> exactly nothing useful, aside from either ignore it (typical for >> clients) or copy it through (typical for middleware). > > The software may not know all the semantics and still do something > useful. Could you give an example of something useful that a real world application would be enabled to do? > Ok, now what if the Atom spec said that all child elements of > are to be considered to be characteristics of that entry, with the > value of those characteristics being given by the content of the > child. Just for clarification, would that preclude things like the following, where the child element of has child elements? ... http://www.x.com/img.jpeg 30 40 > It's also one less job (per extension) for every single developer that > wishes to support extensions. This particular part of their code would > only have to be written once. Off the top of my head, I can't imagine how this would impact the amount of code required in an application. Could you elaborate? From owner-atom-syntax@mail.imc.org Fri Jan 7 16:37: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 QAA01124 for ; Fri, 7 Jan 2005 16:37: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 j07LSn43021037; Fri, 7 Jan 2005 13:28: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 j07LSnxB021036; Fri, 7 Jan 2005 13:28:49 -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 j07LSnt7020964 for ; Fri, 7 Jan 2005 13:28:49 -0800 (PST) (envelope-from lavandowska@gmail.com) Received: by wproxy.gmail.com with SMTP id 40so537148wri for ; Fri, 07 Jan 2005 13:28: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=DLpPNYjw4V3gIAwWAt1avMnVtJw1Pe6oCWMaj9vRWviG/tc6xjTTRDfCBTgaWPaWwgTpjuDGJaQE/UOaUhgK2Lz4/8L2QiRSXRx4zYRpCX4hvECiYIlB/1vDLNiGL9zkxDEgF5BCGJ3BxpeJW8btvaAlUb6u3I95cZR34YbDErM= Received: by 10.54.59.36 with SMTP id h36mr101132wra; Fri, 07 Jan 2005 13:28:48 -0800 (PST) Received: by 10.54.59.5 with HTTP; Fri, 7 Jan 2005 13:28:48 -0800 (PST) Message-ID: <96d7d77c050107132851c5e317@mail.gmail.com> Date: Fri, 7 Jan 2005 15:28:48 -0600 From: Lance Lavandowska Reply-To: Lance Lavandowska To: Tim Bray Subject: Re: Atom extensibility Cc: Atom WG In-Reply-To: <9893A8BA-60EA-11D9-A2C8-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <90FDC7B8-60C3-11D9-A2C8-000A95A51C9E@sun.com> <1f2ed5cd05010710452f652e3@mail.gmail.com> <96d7d77c05010711297eb23404@mail.gmail.com> <9893A8BA-60EA-11D9-A2C8-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The latter. > http://www.imc.org/atom-syntax/mail-archive/msg11850.html is clearer. On Fri, 07 Jan 2005 12:27:48 -0800, Tim Bray wrote: > On Jan 7, 2005, at 11:29 AM, Lance Lavandowska wrote: > > > As a nobody who still cannot quite grasp RDF, I really like Henry's > > proposal. Danny can have his RDF cake, and I can eat it too. > > Oops, Henry says > http://www.imc.org/atom-syntax/mail-archive/msg11850.html is clearer. > Is that what you mean? -Tim > > From owner-atom-syntax@mail.imc.org Fri Jan 7 16:38: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 QAA01163 for ; Fri, 7 Jan 2005 16:38: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 j07LScQd020900; Fri, 7 Jan 2005 13:28: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 j07LScE0020898; Fri, 7 Jan 2005 13:28: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 j07LSbrC020754 for ; Fri, 7 Jan 2005 13:28: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 (rwcrmhc12) with SMTP id <2005010721283401400gkquee>; Fri, 7 Jan 2005 21:28:35 +0000 Date: Fri, 7 Jan 2005 14:28:33 -0700 Subject: Re: RSS extensibility 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: <1546484102.20050107204537@djpowell.net> Message-Id: <158C65EA-60F3-11D9-8D42-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, January 7, 2005, at 01:45 PM, David Powell wrote: > Friday, January 7, 2005, 7:50:49 PM, you wrote: >> I think we must live on different planets. If I propose an extension, >> e.g. embargoDate, and I want anyone to use it, then I'm going to have >> to specify how it works. E.g. " can appear as a >> child of and it gives the embargo date for the entry..." >> Software which wants to *operate* on this is going to have to know >> these semantics. Software which does not know the semantics can do >> exactly nothing useful, aside from either ignore it (typical for >> clients) or copy it through (typical for middleware). > >> I'm sorry, the assertion that it's not clear what's going on the >> example above is just incomprehensible to me. -Tim > > A couple more examples: > > An entry has an ex:digitalSignature property. This is intended to be > a digital signature of that exact instance of an atom entry. > > The entry is annotated using an atom:origin element, and republished > by a Planet*-type site. > > Because the subject of the property wasn't communicated explicitly, > then this property has been republished resulting in an incorrect > signature. If there was a way to tell whether a property applied to an > entry directly, then it would be safe for the republisher to republish > all properties of the entry, even if they were extensions whose > meaning wasn't known to the republisher. > > > Another example might be a property such as ex:rating, intended to > provide slashdot-style ratings specific to the community of readers of > that feed. If those entries are republished, then the original ratings > shouldn't be republished in the aggregate feed. > Are you saying that RDF could help with this situation? If so, could you explain how? From owner-atom-syntax@mail.imc.org Fri Jan 7 16:41: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 QAA01271 for ; Fri, 7 Jan 2005 16: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 j07LVOY7023781; Fri, 7 Jan 2005 13:31: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 j07LVOkY023780; Fri, 7 Jan 2005 13:31:24 -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 j07LVOlq023662 for ; Fri, 7 Jan 2005 13:31: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 <2005010721312001300t8klae>; Fri, 7 Jan 2005 21:31:20 +0000 Date: Fri, 7 Jan 2005 14:31:19 -0700 Subject: Re: Enclosure count 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: <466cecc905010712597c809719@mail.gmail.com> Message-Id: <783F4D37-60F3-11D9-8D42-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, January 7, 2005, at 01:59 PM, David Jacobs wrote: > RSS 2.0 DOES have a one enclosure per entry restriction, so we're > breaking RSS2 compatibility. Why wouldn't multiple enclosures be > multiple posts? Multiple enclosures per entry would make it impossible to translate some Atom feeds to RSS 2.0, but wouldn't affect translation of RSS 2.0 to Atom. I think the latter is the one we're concerned with. From owner-atom-syntax@mail.imc.org Fri Jan 7 16:46: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 QAA01588 for ; Fri, 7 Jan 2005 16:46: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 j07LaeIW028673; Fri, 7 Jan 2005 13:36: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 j07LaeoE028672; Fri, 7 Jan 2005 13:36: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-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 j07LadBL028666 for ; Fri, 7 Jan 2005 13:36:39 -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 j07Laidt008714 for ; Fri, 7 Jan 2005 14: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 <0I9Y006H4UP7BP@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 07 Jan 2005 14:36:44 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9Y005Q4UP7UK@mail.sun.net> for atom-syntax@imc.org; Fri, 07 Jan 2005 14:36:43 -0700 (MST) Date: Fri, 07 Jan 2005 13:36:43 -0800 From: Tim Bray Subject: Re: RSS extensibility In-reply-to: <1f2ed5cd050107123223927528@mail.gmail.com> To: Danny Ayers Cc: atom-syntax@imc.org Message-id: <3950FC00-60F4-11D9-A2C8-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: <1f2ed5cd05010705487956cbbf@mail.gmail.com> <0EB0A912-60C3-11D9-A2C8-000A95A51C9E@sun.com> <1f2ed5cd050107101261b8a1d5@mail.gmail.com> <6DE42CD2-60E5-11D9-A2C8-000A95A51C9E@sun.com> <1f2ed5cd050107123223927528@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 7, 2005, at 12:32 PM, Danny Ayers wrote: > Ok, now what if the Atom spec said that all child elements of > are to be considered to be characteristics of that entry, with the > value of those characteristics being given by the content of the > child. Would you be satisfied with a paragraph that says that those who extend Atom may do so by putting in namespaced elements, and that such elements, when the information they contain is relevant to an entry, SHOULD appear as a child of atom:entry? And I suppose a similar paragraphs concerning atom:feed? -Tim From owner-atom-syntax@mail.imc.org Fri Jan 7 17:08: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 RAA02825 for ; Fri, 7 Jan 2005 17:08: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 j07LxGjb050231; Fri, 7 Jan 2005 13:59: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 j07LxG7D050230; Fri, 7 Jan 2005 13:59:16 -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 j07LxF2F050219 for ; Fri, 7 Jan 2005 13:59:15 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.113] (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 j07LxFKj025464; Fri, 7 Jan 2005 16:59:16 -0500 (EST) Message-ID: <41DF062B.6090400@intertwingly.net> Date: Fri, 07 Jan 2005 16:59:07 -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 Jacobs CC: Atom WG Subject: Re: Enclosure count References: <49ECE2C1-60E8-11D9-A2C8-000A95A51C9E@sun.com> <466cecc905010712597c809719@mail.gmail.com> In-Reply-To: <466cecc905010712597c809719@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: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Jacobs wrote: > RSS 2.0 DOES have a one enclosure per entry restriction, so we're > breaking RSS2 compatibility. Why wouldn't multiple enclosures be > multiple posts? Where does it say that RSS 2.0 has a one enclosure per entry restriction? There have been discussions about whether or not RSS has such a restriction. Some of these discussions took place on the feedvalidator mailing list. Rogers Cadenhead (a member of the RSS Advisory Board) hosted some on his weblog. The current state of RSS enclosures seems to be: there are some tools that produce multiple enclosures per item. And there are some tools which can't handle multiple enclosures per item. Both set of tools can point to the spec to prove that they are "right". http://www.reallysimplesyndication.com/comments?u=reallySimpleSyndic&p=221&link=http%3A%2F%2Fwww.reallysimplesyndication.com%2F2004%2F12%2F21%23a221 http://www.cadenhead.org/workbench/comment/2424 http://sourceforge.net/mailarchive/forum.php?thread_id=6237032&forum_id=37467 http://www.cadenhead.org/workbench/comment/2425 - Sam Ruby From owner-atom-syntax@mail.imc.org Fri Jan 7 17:15: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 RAA03425 for ; Fri, 7 Jan 2005 17:15: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 j07M9Ghc063070; Fri, 7 Jan 2005 14:09: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 j07M9GJ1063068; Fri, 7 Jan 2005 14:09: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.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j07M9FSC063057 for ; Fri, 7 Jan 2005 14:09:15 -0800 (PST) (envelope-from djacobs@gmail.com) Received: by rproxy.gmail.com with SMTP id r35so416699rna for ; Fri, 07 Jan 2005 14:09: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=WuMTdKkSsCbj4AkyNxUp1/UQgFI4p47aZZlgonOGnHO0F4E2Ib+wEztYy9z+5uAQ5pqVZ/voxbeKuQ3RtnUuiui+ibixS2/KGUKMGC2FZXSWiJMYtmuorRdpKFXy3xLGEMphk3t3/X4z7OZyer3ClO1BKgHasArKU/5YRyk1bW0= Received: by 10.38.207.36 with SMTP id e36mr123217rng; Fri, 07 Jan 2005 14:09:19 -0800 (PST) Received: by 10.38.161.22 with HTTP; Fri, 7 Jan 2005 14:09:19 -0800 (PST) Message-ID: <466cecc9050107140979c7d7d2@mail.gmail.com> Date: Fri, 7 Jan 2005 17:09:19 -0500 From: David Jacobs Reply-To: David Jacobs To: Sam Ruby Subject: Re: Enclosure count Cc: Atom WG In-Reply-To: <41DF062B.6090400@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <49ECE2C1-60E8-11D9-A2C8-000A95A51C9E@sun.com> <466cecc905010712597c809719@mail.gmail.com> <41DF062B.6090400@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Well, I had only read one side of the debate, so my information was incomplete. My apologies, and thanks Sam for the response. On Fri, 07 Jan 2005 16:59:07 -0500, Sam Ruby wrote: > David Jacobs wrote: > > RSS 2.0 DOES have a one enclosure per entry restriction, so we're > > breaking RSS2 compatibility. Why wouldn't multiple enclosures be > > multiple posts? > > Where does it say that RSS 2.0 has a one enclosure per entry restriction? > > There have been discussions about whether or not RSS has such a > restriction. Some of these discussions took place on the feedvalidator > mailing list. Rogers Cadenhead (a member of the RSS Advisory Board) > hosted some on his weblog. > > The current state of RSS enclosures seems to be: there are some tools > that produce multiple enclosures per item. And there are some tools > which can't handle multiple enclosures per item. Both set of tools can > point to the spec to prove that they are "right". > > http://www.reallysimplesyndication.com/comments?u=reallySimpleSyndic&p=221&link=http%3A%2F%2Fwww.reallysimplesyndication.com%2F2004%2F12%2F21%23a221 > http://www.cadenhead.org/workbench/comment/2424 > http://sourceforge.net/mailarchive/forum.php?thread_id=6237032&forum_id=37467 > http://www.cadenhead.org/workbench/comment/2425 > > - Sam Ruby > > From owner-atom-syntax@mail.imc.org Fri Jan 7 17:27: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 RAA03837 for ; Fri, 7 Jan 2005 17:27: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 j07MEeSv070064; Fri, 7 Jan 2005 14:14: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 j07MEebM070062; Fri, 7 Jan 2005 14:14: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 j07MEdmS070046 for ; Fri, 7 Jan 2005 14:14:39 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.113] (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 j07MEfCh004222 for ; Fri, 7 Jan 2005 17:14:41 -0500 (EST) Message-ID: <41DF09C8.9090307@intertwingly.net> Date: Fri, 07 Jan 2005 17:14: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 CC: "'Atom WG'" Subject: Atom extensibility, RDF, and GRDDL References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> In-Reply-To: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@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 I'm not sure why this discussion has popped up again, but it seems to me that there will always be people who only can grasp the bits and bytes that actually go across the wire, and there will be several sets of people who can only grasp the higher level abstractions that they see through the lens of their favorite schema aware tool. For quite a while, the compromise seems to have been that the format itself will be defined in terms of what goes over the wire, and that any number of non-normative mappings could be included in the specification. (Non-normative only in the sense that should there ever prove to be an inconsistency, the language in the format specification should prevail). In the case of RDF, there exists a standard means to associate a document with a mapping. This standard is called GRDDL. [1] It defines two mechanisms for associating a document with a stylesheet. A special case (useful for XHTML) is to define a link with a rel of "transformation" to associate this document with an XSL stylesheet. It would seem to me that such an approach would work well with Atom too. A more general mechanism is to define a grddl:interpreter attribute on the root element. Such an approach would work well too. The way I see this working in practice is that should anybody ever actually develop a tool that is capable of doing "partial understanding" in a meaningful and useful manner, there would be a rush on the part of tool developers to add this one element or attribute to any feeds that employ an extension. Meanwhile, it would not be harmful to mention this one element or attribute (anybody have a preference) in the specification. - Sam Ruby [1] http://www.w3.org/TR/grddl/ From owner-atom-syntax@mail.imc.org Fri Jan 7 17:30: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 RAA03983 for ; Fri, 7 Jan 2005 17:30: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 j07MN087080914; Fri, 7 Jan 2005 14:23: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 j07MN0kV080912; Fri, 7 Jan 2005 14:23: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j07MMxgU080723 for ; Fri, 7 Jan 2005 14:22:59 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so641461rnz for ; Fri, 07 Jan 2005 14:22: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:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=HZxt1copXsQ4j0uOguHp1G/oQGHjLvs4Td+3D7WTIoe8WX6rsgtBErd/a5BBilthZMnyg0UbxOWjB2KEYNCZmN9ACP6cGHrbEHn3QTls5xo7FpjlKkRo+Fs79mqy76CkhmkbTEjQ/BiVjkOiLkHkSVYU1el8LtRfwWFDjl2swVQ= Received: by 10.38.8.13 with SMTP id 13mr467815rnh; Fri, 07 Jan 2005 14:22:58 -0800 (PST) Received: by 10.38.179.71 with HTTP; Fri, 7 Jan 2005 14:22:58 -0800 (PST) Message-ID: <1f2ed5cd05010714227acf9b1d@mail.gmail.com> Date: Fri, 7 Jan 2005 23:22:58 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: RSS extensibility Cc: atom-syntax@imc.org In-Reply-To: <3950FC00-60F4-11D9-A2C8-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd05010705487956cbbf@mail.gmail.com> <0EB0A912-60C3-11D9-A2C8-000A95A51C9E@sun.com> <1f2ed5cd050107101261b8a1d5@mail.gmail.com> <6DE42CD2-60E5-11D9-A2C8-000A95A51C9E@sun.com> <1f2ed5cd050107123223927528@mail.gmail.com> <3950FC00-60F4-11D9-A2C8-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 07 Jan 2005 13:36:43 -0800, Tim Bray wrote: > On Jan 7, 2005, at 12:32 PM, Danny Ayers wrote: > > > Ok, now what if the Atom spec said that all child elements of > > are to be considered to be characteristics of that entry, with the > > value of those characteristics being given by the content of the > > child. > > Would you be satisfied with a paragraph that says that those who extend > Atom may do so by putting in namespaced elements, and that such > elements, when the information they contain is relevant to an entry, > SHOULD appear as a child of atom:entry? > > And I suppose a similar paragraphs concerning atom:feed? I think having something along those general lines would be significantly better than the current situation. Obviously I can't speak for anyone else, but if most people were happy with it, I would be too. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Jan 7 17:49: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 RAA05093 for ; Fri, 7 Jan 2005 17:49: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 j07McTG7003262; Fri, 7 Jan 2005 14:38: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 j07McTLB003260; Fri, 7 Jan 2005 14:38:29 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j07McRfG003072; Fri, 7 Jan 2005 14:38:28 -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 <20050107223827.WJBB10495.mta13-winn.mailhost.ntl.com@aamta07-winn.mailhost.ntl.com>; Fri, 7 Jan 2005 22:38:27 +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 <20050107223827.KYYH8064.aamta07-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Fri, 7 Jan 2005 22:38:27 +0000 Date: Fri, 7 Jan 2005 22:38:24 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <59607246.20050107223824@djpowell.net> To: Henry Story CC: "'Atom WG'" , Paul Hoffman / IMC Subject: Re: Atom extensibility In-Reply-To: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.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'd say that the most useful basic features of RDF are: 1) Property names are namespaced for extensibility. 2) Important entities can be assigned global identifiers so that they can be referred to externally. 3) Statements are properties of an object rather than being simple name/value pairs. 4) The model has properties such as monotonicity: which results in statements having a fixed meaning that is not negated by the presence of other statements; this makes it possible to mix vocabularies without needing lots of coordination to prevent them from conflicting. We have 1), and 2) near enough already in Atom. 3) I think would be useful, even if it is just done by an implication in the spec that "sub-elements of entry are properties of the entry", etc. 4) is an important guideline for extension authors I think. If extensions could affect the meaning of core elements or other extensions, it could cause some pretty bad interoperability problems. I think if we ensure that these properties apply to the Atom model, then it will be beneficial to Atom, and will make any mapping between Atom and RDF a lot simpler. -- Dave From owner-atom-syntax@mail.imc.org Fri Jan 7 17:50: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 RAA05125 for ; Fri, 7 Jan 2005 17:50: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 j07MeCor005878; Fri, 7 Jan 2005 14:40: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 j07MeCXZ005877; Fri, 7 Jan 2005 14:40:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j07MeBda005755 for ; Fri, 7 Jan 2005 14:40:11 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta08-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050107224011.RUBK22154.mta09-winn.mailhost.ntl.com@aamta08-winn.mailhost.ntl.com>; Fri, 7 Jan 2005 22:40:11 +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 <20050107224010.YAOS7419.aamta08-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Fri, 7 Jan 2005 22:40:10 +0000 Date: Fri, 7 Jan 2005 22:40:07 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <977337221.20050107224007@djpowell.net> To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: RSS extensibility In-Reply-To: <158C65EA-60F3-11D9-8D42-003065EA6144@geckotribe.com> References: <1546484102.20050107204537@djpowell.net> <158C65EA-60F3-11D9-8D42-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 Friday, January 7, 2005, 9:28:33 PM, you wrote: >> Another example might be a property such as ex:rating, intended to >> provide slashdot-style ratings specific to the community of readers of >> that feed. If those entries are republished, then the original ratings >> shouldn't be republished in the aggregate feed. >> > Are you saying that RDF could help with this situation? If so, could > you explain how? Tim was saying that it was obvious that embargoDate applied to the entry, I was trying to highlight situations where it isn't obvious what object a property is referring to, because the "entry" is quite a complex thing. It can have multiple versions, it can be republished in different feeds etc. I think those situations are both quite difficult, if we spent a long time thinking about it, then we probably could develop some way to identify different concepts, the properties that apply to them, and how these concepts should be processed and propagated by applications. But I think that would be very hard, and a simpler alternative would be just to limit Atom extensions to implicitly being properties of entries, feeds, etc; but to precisely define what we mean by those terms. Either way is RDF-friendly, we are still talking about objects and properties. The current situation isn't quite RDF-friendly though, sub-elements of an entry can be referring to all sorts of different concepts, and without knowing the extension, you can't know what. It would be possible for extensions to be defined such as my two examples where it is not safe for properties to be republished, because they are not solely properties of the entry. I think that aspects of the RDF model are useful, especially wrt. extensibility. Most of these aspects won't really make much difference, if any, to how Atom looks, but might help the interoperability of Atom extensions, and would probably make Atom close enough to the RDF model, that it would be easy to produce a mapping - even if that mapping is produced outside of the WG. See my post to the "Atom extensibility" thread. -- Dave From owner-atom-syntax@mail.imc.org Fri Jan 7 18: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 SAA05575 for ; Fri, 7 Jan 2005 18:01: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 j07MrY0M022616; Fri, 7 Jan 2005 14:53: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 j07MrYsu022615; Fri, 7 Jan 2005 14:53: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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j07MrX3n022571 for ; Fri, 7 Jan 2005 14:53:33 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so642825rnz for ; Fri, 07 Jan 2005 14:53: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=pdJSHD8djMx+e+k6N3uZqpwxHYDjaiTDtoCpeYfmC2TTJB+spVP8FFcMNb1pyS2l4PC3Zj7jEns9kWghw0YNigpGX8ZzDAAYor6MAqRiAz+3rxHoNs7yJL77J5E9jCxU1eh+5JSqJXlHO8gfvp63bqLsTJ7A/3Kiw3EJEMAlC3A= Received: by 10.38.8.13 with SMTP id 13mr477476rnh; Fri, 07 Jan 2005 14:53:35 -0800 (PST) Received: by 10.38.179.71 with HTTP; Fri, 7 Jan 2005 14:53:35 -0800 (PST) Message-ID: <1f2ed5cd05010714533f08c900@mail.gmail.com> Date: Fri, 7 Jan 2005 23:53:35 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Antone Roundy Subject: Re: RSS extensibility Cc: atom-syntax@imc.org In-Reply-To: <24B82B2A-60F2-11D9-8D42-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd050107123223927528@mail.gmail.com> <24B82B2A-60F2-11D9-8D42-003065EA6144@geckotribe.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 7 Jan 2005 14:21:49 -0700, Antone Roundy wrote: > Could you give an example of something useful that a real world > application would be enabled to do? Off the top of my head, how about categorizing entries by their properties. But being able to mix extensions in a predictable fashion is generally nice to have. Last time I looked my own RSS 1.0 feed was using terms from 9 namespaces (mostly through the FOAF output plugin). I could merge with lots of other peoples RSS 1.0 feeds and be sure all the same information would still be available. If it wasn't mapped to a common model (through the structure) I wouldn't even know how to merge. > > Ok, now what if the Atom spec said that all child elements of > > are to be considered to be characteristics of that entry, with the > > value of those characteristics being given by the content of the > > child. > > Just for clarification, would that preclude things like the following, > where the child element of has child elements? > > > ... > > http://www.x.com/img.jpeg > 30 > 40 > > I would expect this to be possible, but the details need to be worked out (i.e. does the parent-child relationship thing go all the way down? - I'd expect not). > > It's also one less job (per extension) for every single developer that > > wishes to support extensions. This particular part of their code would > > only have to be written once. > > Off the top of my head, I can't imagine how this would impact the > amount of code required in an application. Could you elaborate? Ok, say x,y come from one extension (geo) and magnitude another (seismo). The client receives something like this: 10.1 57.3 7 a bit of code could pick these values up with characters[] in SAX or a text node in DOM or whatever XOM sees, but the thing is both geo and seismo are following the same structure but if geo and seismo did things a little differently: 7 a bit of code could pick the magnitude value up as before, but the coords would need different handling - SAX would have to go poking in attributes, DOM would need a getAttribute(), XOM would - ok, I've no idea, but I expect something different. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Jan 7 18:19: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 SAA07523 for ; Fri, 7 Jan 2005 18:19: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 j07N7hl5041933; Fri, 7 Jan 2005 15:07: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 j07N7hsS041932; Fri, 7 Jan 2005 15:07: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 j07N7gsO041918 for ; Fri, 7 Jan 2005 15:07: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 1Cn3Cf-0003Rr-HU; Fri, 07 Jan 2005 23:07:33 +0000 Message-ID: <41DF1641.7060405@franklinmint.fm> Date: Fri, 07 Jan 2005 18:07:45 -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: "'Atom WG'" Subject: Re: Atom extensibility, RDF, and GRDDL References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <41DF09C8.9090307@intertwingly.net> In-Reply-To: <41DF09C8.9090307@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: > I'm not sure why this discussion has popped up again... > > In the case of RDF, there exists a standard means to associate a > document with a mapping. This standard is called GRDDL. [1] > Meanwhile, it would not be harmful to mention this one element or > attribute (anybody have a preference) in the specification. GRDDL addresses the concerns of some participants, but I don't think it addresses the issues being raised by David Powell[0] and myself[1]. I think our question is this: where are extension elements part of the Atom model, and where do they constitute an extension of the Atom model? The arbitrary extension that RDF allows is not what we need--there's a reason almost no one syndicates complex objects in dc:subject statements. Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg11935.html [1] http://www.imc.org/atom-syntax/mail-archive/msg11936.html From owner-atom-syntax@mail.imc.org Fri Jan 7 18:34: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 SAA08165 for ; Fri, 7 Jan 2005 18:34: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 j07NPNhZ062986; Fri, 7 Jan 2005 15:25: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 j07NPNaJ062985; Fri, 7 Jan 2005 15:25:23 -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 j07NPMhq062874 for ; Fri, 7 Jan 2005 15:25:22 -0800 (PST) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so486843wra for ; Fri, 07 Jan 2005 15:25:22 -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=gATNVNQYQbqXbfxRkppfkmOrAmTa92goXx0EVYDH2T72qwqAjZdSJLPH+aAC6mYSVTGNKbujH5DZRmMP4hy5eq02+tanAIRSybCFjr8nBNfrXEJyfkumyUok3KbDjFkRw5Yqp0yjbxEpqoYDuog5nQ3Vdkqj7hRqOO0H8XuZCPg= Received: by 10.54.31.64 with SMTP id e64mr247817wre; Fri, 07 Jan 2005 15:25:22 -0800 (PST) Received: by 10.54.18.53 with HTTP; Fri, 7 Jan 2005 15:25:22 -0800 (PST) Message-ID: <540e373205010715255db0d7ab@mail.gmail.com> Date: Fri, 7 Jan 2005 17:25:22 -0600 From: "Roger B." Reply-To: "Roger B." To: Tim Bray Subject: Re: RSS extensibility Cc: Danny Ayers , atom-syntax@imc.org In-Reply-To: <3950FC00-60F4-11D9-A2C8-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd05010705487956cbbf@mail.gmail.com> <0EB0A912-60C3-11D9-A2C8-000A95A51C9E@sun.com> <1f2ed5cd050107101261b8a1d5@mail.gmail.com> <6DE42CD2-60E5-11D9-A2C8-000A95A51C9E@sun.com> <1f2ed5cd050107123223927528@mail.gmail.com> <3950FC00-60F4-11D9-A2C8-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Would you be satisfied with a paragraph that says that those who extend > Atom may do so by putting in namespaced elements, and that such > elements, when the information they contain is relevant to an entry, > SHOULD appear as a child of atom:entry? Tim: +1, for the sake of compromise if nothing else. Although y'know, having spent some time watching the podcasting crowd develop, I'm beginning to think such a clarification might even be necessary. I'm seeing folks wanting to shove all kinds of stuff into rss:item that actually has nothing to do with the conceptual item. Atom should probably head that impulse off at the pass. -- Roger Benningfield blog: http://admin.support.journurl.com/ From owner-atom-syntax@mail.imc.org Fri Jan 7 18:48: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 SAA08670 for ; Fri, 7 Jan 2005 18:48: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 j07NdhrI082498; Fri, 7 Jan 2005 15:39: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 j07Ndhpl082495; Fri, 7 Jan 2005 15:39:43 -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 j07Ndhax082360 for ; Fri, 7 Jan 2005 15:39:43 -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 <20050107233942013000ckc1e>; Fri, 7 Jan 2005 23:39:43 +0000 Date: Fri, 7 Jan 2005 16:39:41 -0700 Subject: Re: RSS extensibility 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: <1f2ed5cd05010714533f08c900@mail.gmail.com> Message-Id: <67018ACC-6105-11D9-8D42-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, January 7, 2005, at 03:53 PM, Danny Ayers wrote: > On Fri, 7 Jan 2005 14:21:49 -0700, Antone Roundy > wrote: >> Could you give an example of something useful that a real world >> application would be enabled to do? > > Off the top of my head, how about categorizing entries by their > properties. I don't understand. Could I get some example XML, and if the XML doesn't make it obvious, an explanation of how RDF makes this possible where it's not possible lacking RDF? > But being able to mix extensions in a predictable fashion is generally > nice to have. Last time I looked my own RSS 1.0 feed was using terms > from 9 namespaces (mostly through the FOAF output plugin). I could > merge with lots of other peoples RSS 1.0 feeds and be sure all the > same information would still be available. If it wasn't mapped to a > common model (through the structure) I wouldn't even know how to > merge. Again, I don't understand. When you talk of merging feeds, do you mean making a feed out of entries from separate feeds (but where the entries themselves are not altered), or merging the entries themselves, where sometimes the feeds contain different instances of the same entries, resulting in entries containing more data than exists in any one feed? Either way, what information might become unavailable in the process? Maybe once I understand the foregoing, I'll also understand "mapped to a common model (through the structure)". >>> It's also one less job (per extension) for every single developer >>> that >>> wishes to support extensions. This particular part of their code >>> would >>> only have to be written once. >> >> Off the top of my head, I can't imagine how this would impact the >> amount of code required in an application. Could you elaborate? > > Ok, say x,y come from one extension (geo) and magnitude another > (seismo). The client receives something like this: > > > 10.1 > 57.3 > 7 > > > a bit of code could pick these values up with characters[] in SAX or a > text node in DOM or whatever XOM sees, but the thing is both geo and > seismo are following the same structure > > but if geo and seismo did things a little differently: > > > > 7 > > > a bit of code could pick the magnitude value up as before, but the > coords would need different handling - SAX would have to go poking in > attributes, DOM would need a getAttribute(), XOM would - ok, I've no > idea, but I expect something different. > Let me see if I've got this right: you're saying that by standardizing on putting data in element content vs. in attributes, the code would only have to support getting values from element content, and not have to bother with getting attributes? Having typed that sentence, it seems I must be missing something, because the following pseudocode snippets seem only trivially different to me: geox = GetElementContent("/geo:x"); geoy = GetElementContent("/geo:y"); magnitude = GetElementContent("/seismo:magnitude"); geox = GetAttribute("/geo:coords/@x"); geox = GetAttribute("/geo:coords/@y"); magnitude = GetElementContent("/seismo:magnitude"); I'm assuming the client knows something about the geo and seismo extensions--otherwise, I can't imagine what the client would be doing with the extension elements anyway (beyond ignoring it, storing it in an "unknown extension" table, or passing it through to some other application). From owner-atom-syntax@mail.imc.org Fri Jan 7 18:53: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 SAA08926 for ; Fri, 7 Jan 2005 18:53: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 j07NkDhG092006; Fri, 7 Jan 2005 15: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 j07NkDZk092005; Fri, 7 Jan 2005 15:46:13 -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 j07NjsJW091531; Fri, 7 Jan 2005 15:46:12 -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 j07Njxdt017002; Fri, 7 Jan 2005 16:45:59 -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 <0I9Z0064Y0OMBP@edgemail1.Central.Sun.COM>; Fri, 07 Jan 2005 16:45:59 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9Z007ST0OMOP@mail.sun.net>; Fri, 07 Jan 2005 16:45:58 -0700 (MST) Date: Fri, 07 Jan 2005 15:45:58 -0800 From: Tim Bray Subject: Re: Atom extensibility In-reply-to: <59607246.20050107223824@djpowell.net> To: David Powell Cc: Henry Story , "'Atom WG'" , Paul Hoffman / IMC Message-id: <47C36C7E-6106-11D9-A2C8-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: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <59607246.20050107223824@djpowell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 7, 2005, at 2:38 PM, David Powell wrote: > I think if we ensure that these properties apply to the Atom model, > then it will be beneficial to Atom, and will make any mapping between > Atom and RDF a lot simpler. Please propose specific edits to current drafts for the WG's consideration. -Tim From owner-atom-syntax@mail.imc.org Fri Jan 7 19:13: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 TAA10313 for ; Fri, 7 Jan 2005 19:13: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 j0803SAC012734; Fri, 7 Jan 2005 16:03: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 j0803SF6012731; Fri, 7 Jan 2005 16:03: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 j0803RLn012196 for ; Fri, 7 Jan 2005 16:03: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 <20050108000315011003fgm8e>; Sat, 8 Jan 2005 00:03:16 +0000 Date: Fri, 7 Jan 2005 17:03:15 -0700 Subject: Re: Atom extensibility 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: <59607246.20050107223824@djpowell.net> 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 Let me see if I can correctly restate the following in language I'm familiar with--let me know whether I've got this right or not: On Friday, January 7, 2005, at 03:38 PM, David Powell wrote: > I'd say that the most useful basic features of RDF are: > > 1) Property names are namespaced for extensibility. Elements not defined in the Atom core must be namespace qualified (and in a different namespace than Atom, of course). > 2) Important entities can be assigned global identifiers so that they > can be referred to externally. An entry or feed can be referred to from arbitrary places, whether in or out of the feed where it lives, using the value found in its identity construct. > 3) Statements are properties of an object rather than being simple > name/value pairs. Child elements say something about their parents. (This seems so intuitively obvious that I wouldn't think people would make XML that didn't work this way, but from the sound of it, there are examples out there of XML where child elements aren't related to their parents. I for one would understand the importance of making this explicit if I could see such examples). > 4) The model has properties such as monotonicity: which results in > statements having a fixed meaning that is not negated by the > presence > of other statements; this makes it possible to mix vocabularies > without needing lots of coordination to prevent them from > conflicting. No element can change the meaning of its siblings. From owner-atom-syntax@mail.imc.org Fri Jan 7 21:13: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 VAA17324 for ; Fri, 7 Jan 2005 21:13: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 j081vmYa041313; Fri, 7 Jan 2005 17:57: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 j081vmVQ041312; Fri, 7 Jan 2005 17:57:48 -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 j081vlRQ041283 for ; Fri, 7 Jan 2005 17:57:47 -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 j081vbs15142; Sat, 8 Jan 2005 02:57:37 +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 2005010802573541:31458 ; Sat, 8 Jan 2005 02:57:35 +0100 In-Reply-To: <1f2ed5cd05010705487956cbbf@mail.gmail.com> References: <1f2ed5cd05010705487956cbbf@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: Cc: atom-syntax@imc.org From: "Roy T. Fielding" Subject: Re: RSS extensibility Date: Fri, 7 Jan 2005 17:57:35 -0800 To: Danny Ayers X-Mailer: Apple Mail (2.619) X-MIMETrack: Itemize by SMTP Server on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 01/08/2005 02:57:35 AM, Serialize by Router on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 01/08/2005 02:57:37 AM, Serialize complete at 01/08/2005 02:57:37 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: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 7, 2005, at 5:48 AM, Danny Ayers wrote: > In the interests of clarification, consider this pseudo-Atom snippet, > with an extension: > > xmlns:prism="http://prismstandard.org/namespaces/1.2/basic/"> > > > 2005-02-15 > ... > > > A properly defined metadata specification would not define such as an element, but rather as an attribute on the entry element. The reason it is an element in PRISM is because that namespace is intended for RDF descriptions, which are themselves a case of third-party metadata assignment, not mark-up design. > Looking at the PRISM spec (which the namespace qualification > identifies) - > [[ > embargoDate > Earliest date (potentially including time) the resource may be used > according to the rights agreement, or clause in the rights agreement. > ]] And it also says 7 Sharp-eyed readers familiar with RDF may have noticed that the RDF subject of the embargoDate and expirationDate elements is not the Corfu photo, but an anonymous node. That is because those elements do not directly describe the photo. Instead, their interpretation is that the agreement governing the use of the photo imposes such a condition. This interpretation is also used in the geography, industrySector, and usage elements shown in the next example. > So the human meaning of an 'embargoDate' element is reasonably clear. > The problem is that with RSS 2.0's approach to extensibility, there is > no relationship defined between this element and any part of the feed > data. Ok, it's an embargo date. But the embargo date of what? > > On the other hand, following the RSS 1.0 approach to extensibility, > the markup would be interpreted as RDF/XML, which assigns a role for > the different parts of the XML structure. The pseudo-Atom is making > the statement: > > _:entry prism:embargoDate "2005-02-15" . > > The embargoDate is unambiguously a property of the entry. In the RSS > 1.0 case this is defined in the RDF model. No, it isn't, as is clear from the PRISM specification itself. XML does have a built-in containment relation, which is the essence of a mark-up language. RDF/XML does extra work to override that containment relation for the sake of externally-defined metadata. What you ascribe to RDF's inherent characteristics is, in fact, the opposite -- it is XML's native characteristics that are escaped by RDF/XML. Poorly targeted RDF mark-up will be just as vulnerable to misinterpretation as poorly designed XML mark-up, whereas properly designed XML mark-up is syntactically bound through containment to the resource it refers. E.g., stuff to be embargoed XML does have a natural containment relationship that is only violated by specific types of languages that do not actually perform mark-up, namely RDF and its siblings. While I don't see any reason not to make XML's mark-up relations explicit in the specification, I do hope that folks understand that the relationship should be obvious to anyone who does not work in a language that is as perversely non-mark-up as RDF/XML. ....Roy From owner-atom-syntax@mail.imc.org Fri Jan 7 21:43: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 VAA19015 for ; Fri, 7 Jan 2005 21:43: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 j082V1aN060152; Fri, 7 Jan 2005 18:31: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 j082V1XS060151; Fri, 7 Jan 2005 18:31:01 -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 j082V0bb059694 for ; Fri, 7 Jan 2005 18:31:01 -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); Sat, 8 Jan 2005 14:27:24 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 08 Jan 2005 13:26:40 +1100 Subject: Re: RSS extensibility From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <0EB0A912-60C3-11D9-A2C8-000A95A51C9E@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 8/1/05 2:44 AM, "Tim Bray" wrote: >> > xmlns:prism="http://prismstandard.org/namespaces/1.2/basic/"> >> >> 2005-02-15 >> ... >> >> how about a different example 17 ... From owner-atom-syntax@mail.imc.org Fri Jan 7 23: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 XAA25370 for ; Fri, 7 Jan 2005 23:47: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 j084ZHXJ062982; Fri, 7 Jan 2005 20:35: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 j084ZHMp062981; Fri, 7 Jan 2005 20:35: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 j084ZF90062940 for ; Fri, 7 Jan 2005 20:35:17 -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); Sat, 8 Jan 2005 16:35:53 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 08 Jan 2005 15:33:46 +1100 Subject: Re: Atom extensibility 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 8/1/05 11:03 AM, "Antone Roundy" wrote: > (This seems so > intuitively obvious that I wouldn't think people would make XML that > didn't work this way, but from the sound of it, there are examples out > there of XML where child elements aren't related to their parents. I > for one would understand the importance of making this explicit if I > could see such examples). it's often not so much a case of breaking a parent-child relationship, but asserting a sibling relationship ... even in atom, we already have /feed/head/author which applies to /feed/entry. What happens when some moblogger wants to put into /feed/head but have it apply to all /feed/entry except where there are specific for a given ? e. From owner-atom-syntax@mail.imc.org Sat Jan 8 05:15: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 FAA27992 for ; Sat, 8 Jan 2005 05:15: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 j089xJCd028628; Sat, 8 Jan 2005 01:59: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 j089xJP6028627; Sat, 8 Jan 2005 01:59:19 -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 j089xFi4028527 for ; Sat, 8 Jan 2005 01:59:15 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so655764rnz for ; Sat, 08 Jan 2005 01: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=mctMKGFHkth8D+Vz12g/v+prMqR998umHpSb6BTaqsoYJWuEGuyQOFk1fpk7h96hX4ndSd8/KKhbEDeg1KcvwKeb93XDigduVugRR3gGvNN7pdYogw+yc7Uwa9QLesiZjCaw/04Y7ZM7V3JTkxLIr/lLJr370J/Xk7UrBfWaOiY= Received: by 10.38.206.12 with SMTP id d12mr620347rng; Sat, 08 Jan 2005 01:59:12 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sat, 8 Jan 2005 01:59:12 -0800 (PST) Message-ID: <1f2ed5cd05010801594d22db63@mail.gmail.com> Date: Sat, 8 Jan 2005 10:59:12 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Antone Roundy Subject: Re: RSS extensibility Cc: atom-syntax@imc.org In-Reply-To: <67018ACC-6105-11D9-8D42-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd05010714533f08c900@mail.gmail.com> <67018ACC-6105-11D9-8D42-003065EA6144@geckotribe.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 7 Jan 2005 16:39:41 -0700, Antone Roundy wrote: > > On Friday, January 7, 2005, at 03:53 PM, Danny Ayers wrote: > > On Fri, 7 Jan 2005 14:21:49 -0700, Antone Roundy > > wrote: > >> Could you give an example of something useful that a real world > >> application would be enabled to do? > > > > Off the top of my head, how about categorizing entries by their > > properties. > > I don't understand. Could I get some example XML, and if the XML > doesn't make it obvious, an explanation of how RDF makes this possible > where it's not possible lacking RDF? Say your system is aggregating material from two sensors, and you get the following, one from each: http://123 2005-02-02 10.1 57.3 http://123 2005-02-03 7 It isn't clear how these should be merged - does the entry with the later date replace the earlier one? The (presumably) desired behaviour is for the geo+seismo properties all to appear as elements under (properties of) the entry. Mapping syntax to a model can help decide what to do *in the general case* rather than per-extension. As it happens, RSS/RDF would only go part of the way with something like this - you'd get the desired merged entry, but with two dates. > > But being able to mix extensions in a predictable fashion is generally > > nice to have. Last time I looked my own RSS 1.0 feed was using terms > > from 9 namespaces (mostly through the FOAF output plugin). I could > > merge with lots of other peoples RSS 1.0 feeds and be sure all the > > same information would still be available. If it wasn't mapped to a > > common model (through the structure) I wouldn't even know how to > > merge. > > Again, I don't understand. When you talk of merging feeds, do you mean > making a feed out of entries from separate feeds (but where the entries > themselves are not altered), or merging the entries themselves, where > sometimes the feeds contain different instances of the same entries, > resulting in entries containing more data than exists in any one feed? > Either way, what information might become unavailable in the process? > Maybe once I understand the foregoing, I'll also understand "mapped to > a common model (through the structure)". There is a predictable way of being able to combine *any* two RDF/XML documents, whatever vocabularies are used. XML alone doesn't provide this. > >>> It's also one less job (per extension) for every single developer > >>> that > >>> wishes to support extensions. This particular part of their code > >>> would > >>> only have to be written once. > >> > >> Off the top of my head, I can't imagine how this would impact the > >> amount of code required in an application. Could you elaborate? > > > > Ok, say x,y come from one extension (geo) and magnitude another > > (seismo). The client receives something like this: > > > > > > 10.1 > > 57.3 > > 7 > > > > > > a bit of code could pick these values up with characters[] in SAX or a > > text node in DOM or whatever XOM sees, but the thing is both geo and > > seismo are following the same structure > > > > but if geo and seismo did things a little differently: > > > > > > > > 7 > > > > > > a bit of code could pick the magnitude value up as before, but the > > coords would need different handling - SAX would have to go poking in > > attributes, DOM would need a getAttribute(), XOM would - ok, I've no > > idea, but I expect something different. > > > Let me see if I've got this right: you're saying that by standardizing > on putting data in element content vs. in attributes, the code would > only have to support getting values from element content, and not have > to bother with getting attributes? Having typed that sentence, it > seems I must be missing something, because the following pseudocode > snippets seem only trivially different to me: > > geox = GetElementContent("/geo:x"); > geoy = GetElementContent("/geo:y"); > magnitude = GetElementContent("/seismo:magnitude"); > > geox = GetAttribute("/geo:coords/@x"); > geox = GetAttribute("/geo:coords/@y"); > magnitude = GetElementContent("/seismo:magnitude"); Yes, trivially different, two extra lines of code. Potentially for every developer, for every extension. > I'm assuming the client knows something about the geo and seismo > extensions--otherwise, I can't imagine what the client would be doing > with the extension elements anyway (beyond ignoring it, storing it in > an "unknown extension" table, or passing it through to some other > application). The 'what to do with unknown extensions' question is something that makes a lot more sense if you have commited to the full RDF model. For example, your system might have a piece of data stored: ... John Smith You might later pick up the statement: So your system would know to list anything marked xxx:wibble along with the other contributors. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Jan 8 05:38: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 FAA28938 for ; Sat, 8 Jan 2005 05:38: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 j08ALTVE039842; Sat, 8 Jan 2005 02:21: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 j08ALTSv039841; Sat, 8 Jan 2005 02:21: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.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j08ALTlF039832 for ; Sat, 8 Jan 2005 02:21:29 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so656056rnz for ; Sat, 08 Jan 2005 02:21: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=Qvze/c2XJS0rMzZDH4Jo2IwyOuWg0JUFo4E/HWUVzqXGsz2Uf+wUQ/BVI/vRU/X3mNhl5GITtvLbVM2pEHMdBeCmD9ye63gDnM8uPu1m7G7CFcezmFcDkzKq858s5u1UdpbgZwFzrHKAG4vbPXvgkFK2PaJx4rYJI1EN7cHvUkY= Received: by 10.38.8.13 with SMTP id 13mr618231rnh; Sat, 08 Jan 2005 02:21:29 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sat, 8 Jan 2005 02:21:29 -0800 (PST) Message-ID: <1f2ed5cd0501080221230cfb4@mail.gmail.com> Date: Sat, 8 Jan 2005 11:21:29 +0100 From: Danny Ayers Reply-To: Danny Ayers To: "Roy T. Fielding" Subject: Re: RSS extensibility Cc: atom-syntax@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd05010705487956cbbf@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 7 Jan 2005 17:57:35 -0800, Roy T. Fielding wrote: > And it also says > > 7 Sharp-eyed readers... I was only providing an example for demonstration purposes. Broad brush strokes. > > _:entry prism:embargoDate "2005-02-15" . > > > > The embargoDate is unambiguously a property of the entry. In the RSS > > 1.0 case this is defined in the RDF model. > > No, it isn't, as is clear from the PRISM specification itself. XML > does have a built-in containment relation, which is the essence of a > mark-up language. RDF/XML does extra work to override that containment > relation for the sake of externally-defined metadata. What you ascribe > to RDF's inherent characteristics is, in fact, the opposite -- it is > XML's native characteristics that are escaped by RDF/XML. Perhaps I wasn't clear enough. XML has containment. Individual specifications may assign it semantics. RDF/XML assigns it semantics corresponding to the RDF model. Without either the individual specification's definition, or a generalised interpretation like RDF/XML's all you have is syntax featuring containment. > Poorly targeted RDF mark-up will be just as vulnerable to > misinterpretation > as poorly designed XML mark-up, whereas properly designed XML mark-up is > syntactically bound through containment to the resource it refers. > E.g., > > stuff to be embargoed > > XML does have a natural containment relationship that is only violated > by specific types of languages that do not actually perform mark-up, > namely RDF and its siblings. But XML containment can only express tree structures. To express graph structures, the containment must somehow be violated. RDF is a graph. (RDF/XML could probably have made a lot better use of XML's structure, but it's a bit late in the day now). While I don't see any reason not to make > XML's mark-up relations explicit in the specification, That pleases me. That's all I'm hoping for. I do hope that > folks > understand that the relationship should be obvious to anyone who does > not > work in a language that is as perversely non-mark-up as RDF/XML. Well there you have it - it is possible to design XML languages that are perverse. So we can't rely on everyone following the 'obvious' relationship pattern. Making it explicit should help prevent misinterpretation. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Jan 8 07:12: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 HAA03056 for ; Sat, 8 Jan 2005 07:12: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 j08C0Sh5093394; Sat, 8 Jan 2005 04:00: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 j08C0S9t093392; Sat, 8 Jan 2005 04:00: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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j08C0QjQ093344 for ; Sat, 8 Jan 2005 04:00:27 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta02-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050108120022.IARK15658.mta08-winn.mailhost.ntl.com@aamta02-winn.mailhost.ntl.com>; Sat, 8 Jan 2005 12:00:22 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta02-winn.mailhost.ntl.com with ESMTP id <20050108120021.FULI11644.aamta02-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Sat, 8 Jan 2005 12:00:21 +0000 Date: Sat, 8 Jan 2005 12:00:19 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <573271774.20050108120019@djpowell.net> To: Danny Ayers CC: Antone Roundy , atom-syntax@imc.org Subject: Re: RSS extensibility In-Reply-To: <1f2ed5cd05010801594d22db63@mail.gmail.com> References: <1f2ed5cd05010714533f08c900@mail.gmail.com> <67018ACC-6105-11D9-8D42-003065EA6144@geckotribe.com> <1f2ed5cd05010801594d22db63@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 Saturday, January 8, 2005, 9:59:12 AM, you wrote: > Say your system is aggregating material from two sensors, and you get > the following, one from each: > > http://123 > 2005-02-02 > 10.1 > 57.3 > > > http://123 > 2005-02-03 > 7 > > It isn't clear how these should be merged - does the entry with the > later date replace the earlier one? The (presumably) desired behaviour > is for the geo+seismo properties all to appear as elements under > (properties of) the entry. Mapping syntax to a model can help decide > what to do *in the general case* rather than per-extension. As it > happens, RSS/RDF would only go part of the way with something like > this - you'd get the desired merged entry, but with two dates. I think that reason that RDF is only helping partially here is that you have a simplified model of an entry that is actually only modelling the state of an entry at a point in time, when actually entries are expected to vary over time and have multiple instances. This is fine, it is a useful simplification; models are supposed to be simplifications. But you can't then expect to merge two different instances of the entry under this model using simple RDF graph merging, because the model is an over-simplification. Eg: If you merged: http://123 2005-02-03 7 and http://123 2005-02-04 7.5 ... you would get: http://123 2005-02-03 2005-02-04 7.5 7 Not very useful. A solution for RDF-based applications wanting to merge incoming RSS and get a consistent RDF model is to either have special application-level merging logic that knows about the simplification that has been made; or to have a model where instances of an entry are modelled explicitly. If the instances have ids, then you can allow for both posting new instances of entries, and annotating existing instances with extra information. Its a tradeoff between flexibility and complexity. -- Dave From owner-atom-syntax@mail.imc.org Sat Jan 8 07: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 HAA04351 for ; Sat, 8 Jan 2005 07: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 j08CUHm2011953; Sat, 8 Jan 2005 04:30: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 j08CUHJs011951; Sat, 8 Jan 2005 04:30: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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j08CUHC0011907 for ; Sat, 8 Jan 2005 04:30:17 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so657815rnz for ; Sat, 08 Jan 2005 04:30: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=exgRnwr4v4DIg/eGOQ7XbVWUWLETA9SnJ559R3iH7uj2GFvXtrsz83e4Zbd5jmscLztpoNiSxCc+8DKWPb+I+y/FYmGjBPTCQgpccBA3AoyJVyfFD1p4KTBthY/7KmOrvkzZfOXTqfuLy+xCvrl2yrWj5xW3/H+daOu293QKnjw= Received: by 10.38.206.12 with SMTP id d12mr645768rng; Sat, 08 Jan 2005 04:30:13 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sat, 8 Jan 2005 04:30:13 -0800 (PST) Message-ID: <1f2ed5cd05010804303a9eca43@mail.gmail.com> Date: Sat, 8 Jan 2005 13:30:13 +0100 From: Danny Ayers Reply-To: Danny Ayers To: David Powell Subject: Re: RSS extensibility Cc: Antone Roundy , atom-syntax@imc.org In-Reply-To: <573271774.20050108120019@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd05010714533f08c900@mail.gmail.com> <67018ACC-6105-11D9-8D42-003065EA6144@geckotribe.com> <1f2ed5cd05010801594d22db63@mail.gmail.com> <573271774.20050108120019@djpowell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 8 Jan 2005 12:00:19 +0000, David Powell wrote: Its a tradeoff between flexibility > and complexity. Indeed. There was recently some coverage on-list about using a richer model (in RDF), specifically to preserve provenance. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Jan 8 10:14: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 KAA12166 for ; Sat, 8 Jan 2005 10:14: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 j08F0hjt041222; Sat, 8 Jan 2005 07:00: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 j08F0hYj041215; Sat, 8 Jan 2005 07:00:43 -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 j08F0h8W041143 for ; Sat, 8 Jan 2005 07:00:43 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 78922 invoked by uid 17064); 8 Jan 2005 15:00:43 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.251.47.193]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 8 Jan 2005 15:00:43 -0000 In-Reply-To: <573271774.20050108120019@djpowell.net> References: <1f2ed5cd05010714533f08c900@mail.gmail.com> <67018ACC-6105-11D9-8D42-003065EA6144@geckotribe.com> <1f2ed5cd05010801594d22db63@mail.gmail.com> <573271774.20050108120019@djpowell.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <035A9182-6186-11D9-8C94-000A95D9FA7A@bblfish.net> Cc: Antone Roundy , Danny Ayers , David Powell From: Henry Story Subject: Re: RSS extensibility Date: Sat, 8 Jan 2005 16:00:19 +0100 To: "'Atom WG'" X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j08F0h8W041206 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I think this is a very nice example, and will show the power of seeing atom as RDF. If we accept that the atom syntax is an RDF syntax [Ø] then we can draw the two entries in the ascii graph notation [1] as follows. _f1 ---is a---> |----head----> .... |----entry---> _e1 --is a---> |----id-----> |---date----> "2005-02-02T13:05:04"^^xsd:dateTime |---geo:x--->"10.1" |---geo:y--->"57.3" _f2 ---is a---> |----head----> .... |----entry---> _e2 --is a---> |----id-----> |---date----> "2005-02-03T07:05:04"^^xsd:dateTime |---seismo:magnitude--->"7" let us take the point of view now of a simple machine confronted by these two entries. Should it merge these two entries or should it leave them as separate? The machine that parses this could now look up the atom owl document located at the atom name space location, where it would find out that the and the relations are functional [2], so can only have one value. Since _e1 and _e2 are related to different dates it follows that _e1 and _e2 are not the same and so should not be merged. Now the problem with the graph above, is that it does not make sense to assign a geo location to an entry. This will probably not be allowed by the geo ontology, which will probably specify some location class to be the the subject of such a relation. One may want to imagine some weird monster called a Entry-geolocation, but it will have all kinds of weird properties. So let us be throw that monster out of the window, even though it makes xml sense: it does not make any other sense at all. This is probably what was meant: _f1 ---is a---> |----head----> _h1 | |---author-> _p1 ---is a---> | |----email---> henry.story@bblfish.net | |----entry---> _e1 --is a---> |----id-----> |---date----> "2005-02-02T13:05:04"^^xsd:dateTime |--content--> _p1 ---is a ---> |--foaf:home--> _loc ---is a---> | |---geo:x--->"10.1" | |---geo:y--->"57.3" |--foaf:mbox--> _f2 ---is a---> |--head--> .... |--entry-> _e2 --is a---> |----id-----> |---date----> "2005-03-02T07:05:04"^^xsd:dateTime |--content--> _event1 ---is a ---> |--phy:date-->"2005-02-02T13:05:04"^^xsd:dateTime |--phy:loc---> _loc2 --is a ---> | |--geo:x-------> "10.1" | |--geo:y-------> "57.3" |--seismo:magnitude-->"7" So here again the machine can see that it has two entries. Since _e1 and _e2 have different dates and different ids. But the machine can go on its merry way and deduce some other interesting things. It can take notice that the location of the home of person _p1 is the same as the location of _event1. It knows this because by downloading the OWL ontology description of the geo ontology it will find that the geo:x and geo:y properties are functional too, and that combined they are inverse functinal.[3] So it knows that _loc1 and _loc2 are the same. These can then be merged. As a result it knows that _event1 occurred at the location of the home of person _p1. It still does not know that this occurrence was at at time during which _p1 had his home there. Perhaps another entry somewhere else will have that information. Perhaps somewhere else there would be foaf:knows information that relates the author of the feed _f1 to _p1, and this would be again some very useful information. Ok. So what can we deduce from the above: - it is possible to have nonsensical but well formed xml - well defined Ontologies can help create extensions to atom that make sense - These ontologies then allow certain deductions to be made by in the know software that can be very valuable. Henry Story [0] http://www.imc.org/atom-syntax/mail-archive/msg11850.html [1] one does not have to understand graph theory to understand this, just as one does not have to understand set theory to check that one has been given the correct change. As a notational convention variables such as _f1 and _f2 are blank nodes. , , are URIs. ----date----> is a directed relation between the Node on the left and the node on the right which as a url of atom:date. [2] functional in the same way as f(x)=y means that for all x there is only one mapped y. If f is the times 2 function the f(7)=14. This is why the square root function only covers positive real numbers because if it did not it would not be functional and sqrt(-4) = -2 and +2 [3] I am not sure this can be defined as it stands in OWL, but clearly it could. On 8 Jan 2005, at 13:00, David Powell wrote: > > > Saturday, January 8, 2005, 9:59:12 AM, you wrote: > >> Say your system is aggregating material from two sensors, and you get >> the following, one from each: > >> >> http://123 >> 2005-02-02 >> 10.1 >> 57.3 >> > >> >> http://123 >> 2005-02-03 >> 7 >> > >> It isn't clear how these should be merged - does the entry with the >> later date replace the earlier one? The (presumably) desired behaviour >> is for the geo+seismo properties all to appear as elements under >> (properties of) the entry. Mapping syntax to a model can help decide >> what to do *in the general case* rather than per-extension. As it >> happens, RSS/RDF would only go part of the way with something like >> this - you'd get the desired merged entry, but with two dates. > > I think that reason that RDF is only helping partially here is that > you have a simplified model of an entry that is actually only > modelling the state of an entry at a point in time, when actually > entries are expected to vary over time and have multiple instances. > > This is fine, it is a useful simplification; models are supposed to be > simplifications. > > But you can't then expect to merge two different instances of the > entry under this model using simple RDF graph merging, because the > model is an over-simplification. > > Eg: If you merged: > > > http://123 > 2005-02-03 > 7 > > > and > > > http://123 > 2005-02-04 > 7.5 > > > ... you would get: > > > http://123 > 2005-02-03 > 2005-02-04 > 7.5 > 7 > > > Not very useful. > > > A solution for RDF-based applications wanting to merge incoming RSS > and get a consistent RDF model is to either have special > application-level merging logic that knows about the simplification > that has been made; or to have a model where instances of an entry are > modelled explicitly. If the instances have ids, then you can allow for > both posting new instances of entries, and annotating existing > instances with extra information. Its a tradeoff between flexibility > and complexity. > > > -- > Dave > From owner-atom-syntax@mail.imc.org Sat Jan 8 10: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 KAA14672 for ; Sat, 8 Jan 2005 10: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 j08FloAn010525; Sat, 8 Jan 2005 07:47: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 j08Flodu010521; Sat, 8 Jan 2005 07:47: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.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j08FlnOi010349 for ; Sat, 8 Jan 2005 07:47:50 -0800 (PST) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so561085wra for ; Sat, 08 Jan 2005 07:47: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=CineiQEGOdhE6ujkh/UdJ44Df7ompQmKIRaHzABrIAtFWefX8aYrDBdPk3uLt61fZc6U6KdNFEzJ+24c/LjJFg30GvenOEtgMRt/PWyTkrWExCHbedcIkxUOJURFG6L8FUJEl4ZgBmZuvXObqd3PotPbQ4HL/sbVsySFmP6LV/0= Received: by 10.54.51.30 with SMTP id y30mr18083wry; Sat, 08 Jan 2005 07:47:47 -0800 (PST) Received: by 10.54.18.2 with HTTP; Sat, 8 Jan 2005 07:47:47 -0800 (PST) Message-ID: <540e373205010807475632ffa5@mail.gmail.com> Date: Sat, 8 Jan 2005 09:47:47 -0600 From: "Roger B." Reply-To: "Roger B." To: Atom WG Subject: Re: RSS extensibility In-Reply-To: <035A9182-6186-11D9-8C94-000A95D9FA7A@bblfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd05010714533f08c900@mail.gmail.com> <67018ACC-6105-11D9-8D42-003065EA6144@geckotribe.com> <1f2ed5cd05010801594d22db63@mail.gmail.com> <573271774.20050108120019@djpowell.net> <035A9182-6186-11D9-8C94-000A95D9FA7A@bblfish.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > I think this is a very nice example, and will show the power of seeing > atom as RDF. Henry: I hope it isn't too depressing to know that, at least for this individual, it really doesn't. To me, you've just sketched out a solution in search of a problem... there are far, far easier ways of getting the same results. Like, say, putting the geo and seismo data together in the entry to begin with. After all, absent a signing mechanism, merging two entries with the same atom:id is only going to get you in trouble. It'd be far simpler for the publisher of Feed A and Feed B to just do any merging on her own (she doesn't need a machine to deduce any relationships within her own data, after all) and produce a Feed C that saves everyone the trouble. > Should it merge these two entries or should it leave > them as separate? In my case, the later entry is ignored... existing entries are never updated once they're in the database. A different app would probably either (a) completely overwrite the old entry with the new one, or (b) declare them to be two distinct versions of the same entry. In any case, there's little pressing need to try and create a Frankenstein's Entry from the two. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Sat Jan 8 11: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 LAA16084 for ; Sat, 8 Jan 2005 11:16: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 j08G7eK3038239; Sat, 8 Jan 2005 08:07: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 j08G7eJh038238; Sat, 8 Jan 2005 08:07:40 -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 j08G7dcB038032 for ; Sat, 8 Jan 2005 08:07:39 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 50893 messnum 6480516 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 8 Jan 2005 16:07:36 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.150?) (83.70.164.213) by mail12.svc.cra.dublin.eircom.net (qp 50893) with SMTP; 8 Jan 2005 16:07:36 -0000 Message-ID: <41E0055C.5070605@dehora.net> Date: Sat, 08 Jan 2005 16:07:56 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'Atom WG'" Subject: Re: Atom extensibility References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <59607246.20050107223824@djpowell.net> In-Reply-To: <59607246.20050107223824@djpowell.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 David Powell wrote: > > I'd say that the most useful basic features of RDF are: > > 1) Property names are namespaced for extensibility. > > 2) Important entities can be assigned global identifiers so that they > can be referred to externally. > > [...] > > We have 1), and 2) near enough already in Atom. David, I've stated my position elsewhere, but I wanted to qualify what you said there. Atom in my mind does not provide extensibility, it provides modularity. Sure, that's nitpicky, but I think it's a useful distinction to hold. Whether modularity is sufficient for Atom's evolution as a format is a separate matter. cheers Bill From owner-atom-syntax@mail.imc.org Sat Jan 8 11:18: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 LAA16152 for ; Sat, 8 Jan 2005 11:18: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 j08G3UKe031836; Sat, 8 Jan 2005 08:03: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 j08G3UfD031835; Sat, 8 Jan 2005 08:03:30 -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 j08G3TqK031715 for ; Sat, 8 Jan 2005 08:03:29 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 78588 messnum 4158215 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 8 Jan 2005 16:03:26 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.150?) (83.70.164.213) by mail00.svc.cra.dublin.eircom.net (qp 78588) with SMTP; 8 Jan 2005 16:03:26 -0000 Message-ID: <41E00461.4000705@dehora.net> Date: Sat, 08 Jan 2005 16:03:45 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'Atom WG'" Subject: Re: Atom extensibility References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <90FDC7B8-60C3-11D9-A2C8-000A95A51C9E@sun.com> In-Reply-To: <90FDC7B8-60C3-11D9-A2C8-000A95A51C9E@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: > I think that the charter requirements on extensibility will be filled > adequately with PaceExtendingAtom. I think they would be filled still > better by adopting PaceMustUnderstandElement, but apparently others are > unconvinced. Extensibility via a mapping to RDF seems to me to add a > lot of complexity (most people have never bothered to learn graph > theory) without any real benefit. -Tim I won't talk about 'complexity' here, but will talk about cost/benefit. My take on this is that extensibility via a mapping to RDF seems to me to add cost for implementors and those processing Atom. Writing Atom as RDF is cheap enough. Not enough people are processing RSS1.0 and other RDF formats *as* RDF; I speculate that indicates an issue on receipt of the data. I'm +1 on not requiring an RDF mapping for Atom. Those of us that like to use RDF can figure out how to. cheers Bill From owner-atom-syntax@mail.imc.org Sat Jan 8 11:28: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 LAA16602 for ; Sat, 8 Jan 2005 11:28: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 j08GEnsB048166; Sat, 8 Jan 2005 08:14: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 j08GEnSq048163; Sat, 8 Jan 2005 08:14:49 -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 j08GEmKA048048 for ; Sat, 8 Jan 2005 08:14:48 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 77666 messnum 6479946 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 8 Jan 2005 16:14:45 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.150?) (83.70.164.213) by mail12.svc.cra.dublin.eircom.net (qp 77666) with SMTP; 8 Jan 2005 16:14:45 -0000 Message-ID: <41E00709.5020209@dehora.net> Date: Sat, 08 Jan 2005 16:15:05 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'Atom WG'" Subject: Re: Atom extensibility, RDF, and GRDDL References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <41DF09C8.9090307@intertwingly.net> In-Reply-To: <41DF09C8.9090307@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: > In the case of RDF, there exists a standard means to associate a > document with a mapping. This standard is called GRDDL. [1] > > [...] > > Meanwhile, it would not be harmful to mention this one element or > attribute (anybody have a preference) in the specification. It's not clear to me that GRDDL is planned to become a recommendation. Does anyone know what the roadmap for GRDDL is? Sam I'm tempted to use the 'put in the implementors guide' - calling GRDDL a standard is a reach imho. cheers Bill From owner-atom-syntax@mail.imc.org Sat Jan 8 11: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 LAA16818 for ; Sat, 8 Jan 2005 11: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 j08GN7A8057039; Sat, 8 Jan 2005 08:23: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 j08GN7AA057035; Sat, 8 Jan 2005 08:23:07 -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 j08GN6LJ056895 for ; Sat, 8 Jan 2005 08:23:07 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 89883 messnum 3867212 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 8 Jan 2005 16:23:03 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.150?) (83.70.164.213) by mail08.svc.cra.dublin.eircom.net (qp 89883) with SMTP; 8 Jan 2005 16:23:03 -0000 Message-ID: <41E008FB.7060609@dehora.net> Date: Sat, 08 Jan 2005 16:23:23 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'Atom WG'" Subject: Re: Atom extensibility, RDF, and GRDDL References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <41DF09C8.9090307@intertwingly.net> <41DF1641.7060405@franklinmint.fm> In-Reply-To: <41DF1641.7060405@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: > GRDDL addresses the concerns of some participants, but I don't think it > addresses the issues being raised by David Powell[0] and myself[1]. > I think our question is this: where are extension elements part of the > Atom model, and where do they constitute an extension of the Atom model? Robert, My answer to this question is that Atom doesn't have a model in terms of being able to talk about extension so there's no point discussing it. Extensibility is probably out of scope for the format. cheers Bill From owner-atom-syntax@mail.imc.org Sat Jan 8 12:05: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 MAA18482 for ; Sat, 8 Jan 2005 12:05: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 j08GsNOD073031; Sat, 8 Jan 2005 08:54: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 j08GsN3b073030; Sat, 8 Jan 2005 08:54:23 -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 j08GsNGK073013 for ; Sat, 8 Jan 2005 08:54:23 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 17984 messnum 5115973 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 8 Jan 2005 16:54:20 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.150?) (83.70.164.213) by mail13.svc.cra.dublin.eircom.net (qp 17984) with SMTP; 8 Jan 2005 16:54:20 -0000 Message-ID: <41E0104F.1080008@dehora.net> Date: Sat, 08 Jan 2005 16:54:39 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: atom-syntax@imc.org Subject: Re: RSS extensibility References: <1f2ed5cd05010705487956cbbf@mail.gmail.com> <0EB0A912-60C3-11D9-A2C8-000A95A51C9E@sun.com> <1f2ed5cd050107101261b8a1d5@mail.gmail.com> <6DE42CD2-60E5-11D9-A2C8-000A95A51C9E@sun.com> <1f2ed5cd050107123223927528@mail.gmail.com> <3950FC00-60F4-11D9-A2C8-000A95A51C9E@sun.com> In-Reply-To: <3950FC00-60F4-11D9-A2C8-000A95A51C9E@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: > Would you be satisfied with a paragraph that says that those who extend > Atom may do so by putting in namespaced elements, and that such > elements, when the information they contain is relevant to an entry, > SHOULD appear as a child of atom:entry? Replace 'extend' with 'add information' and I'm +1. cheers Bill From owner-atom-syntax@mail.imc.org Sat Jan 8 12:05: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 MAA18505 for ; Sat, 8 Jan 2005 12:05: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 j08GxKVo074234; Sat, 8 Jan 2005 08:59: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 j08GxK7E074232; Sat, 8 Jan 2005 08:59: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 j08GxKJC074225 for ; Sat, 8 Jan 2005 08:59:20 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 84547 invoked by uid 17064); 8 Jan 2005 16:59:23 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.251.47.193]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 8 Jan 2005 16:59:23 -0000 In-Reply-To: <540e373205010807475632ffa5@mail.gmail.com> References: <1f2ed5cd05010714533f08c900@mail.gmail.com> <67018ACC-6105-11D9-8D42-003065EA6144@geckotribe.com> <1f2ed5cd05010801594d22db63@mail.gmail.com> <573271774.20050108120019@djpowell.net> <035A9182-6186-11D9-8C94-000A95D9FA7A@bblfish.net> <540e373205010807475632ffa5@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <975765E2-6196-11D9-8C94-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: "Roger B." From: Henry Story Subject: Re: RSS extensibility Date: Sat, 8 Jan 2005 17:58:59 +0100 To: "'Atom WG'" X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 8 Jan 2005, at 16:47, Roger B. wrote: >> I think this is a very nice example, and will show the power of seeing >> atom as RDF. > > Henry: I hope it isn't too depressing to know that, at least for this > individual, it really doesn't. To me, you've just sketched out a > solution in search of a problem... there are far, far easier ways of > getting the same result Which result? I showed many different things... 0) I had previously already shown that one can see Atom to be RDF, without any syntax changes. 1) I showed that seeing Atom as RDF makes it easy to structure atom extensions. It gives us a framework for making intelligent extension decisions. 2) I showed also how one could use the rdf graph information and owl information to make decisions on how to merge some information and make deductions on that information. 3) I also showed how one could have nonsensical yet well formed xml, and how thinking in terms of ontologies (very similar to class diagrams in OO programming) made this much more apparent. Clearly there is nothing complicated about 0) above. For those that don't care about RDF, ie: most simple aggregators at first, they won't need anything more than a simple xml parser. For them there is nothing to it. They can just ignore anything that is outside the atom namespace. I think for the rest of the points above the argument is pretty much the same. If you don't want to create extensions, having a framework with which to do them won't be of any interest to you. But for those who do it makes a *huge* difference. For those that don't care to reason about the data the structure made available by rdf is not of great interest. But that does not make it not useful to others. You can look at the web with a black and white browser, and not care about color tags in your html. That was not a reason for excluding color tags from the spec. > Like, say, putting the geo and seismo data together in the entry to > begin with. After all, absent a signing mechanism, merging two entries > with the same atom:id is only going to get you in trouble. It'd be far > simpler for the publisher of Feed A and Feed B to just do any merging > on her own (she doesn't need a machine to deduce any relationships > within her own data, after all) and produce a Feed C that saves > everyone the trouble. I can't at the same time show how you can do deductions and also show how one sets up a trust network, and everything else that entails in one e-mail... >> Should it merge these two entries or should it leave >> them as separate? > > In my case, the later entry is ignored... existing entries are never > updated once they're in the database. A different app would probably > either (a) completely overwrite the old entry with the new one, or (b) > declare them to be two distinct versions of the same entry. In BlogEd I do (b) and what you do. IE. I never change an entry in the database and I would declare them to be different version of each other. Ie: I have two entries pointing to the same EntryID, which is exactly what the spec says. > > In any case, there's little pressing need to try and create a > Frankenstein's Entry from the two. I don't think you understood what I was trying to say in my mail there. Perhaps I was not clear. I showed how one could use machine readable information to deduce that the two entries should not be merged. This deduction could be done by a machine using that data of course or simply hardcoded by a human programmer who wrote the storage layer. That is indeed the correct behavior and it is the one that your program exhibits (it throws one entry away, but what you do with your data is completely up to you) The "Frankenstein Entry" was in relation to this graph: _f1 ---is a---> |----head----> .... |----entry---> _e1 --is a---> |----id-----> |---date----> "2005-02-02T13:05:04"^^xsd:dateTime |---geo:x--->"10.1" |---geo:y--->"57.3" in particular this subgraph: _e1 --is a---> |----id-----> |---date----> "2005-02-02T13:05:04"^^xsd:dateTime |---geo:x--->"10.1" |---geo:y--->"57.3" which corresponds to the xml http://123 2005-02-02 10.1 57.3 Here our RDF model (or Tim Bray's intuition) would say that the geo:x and geo:y properties are properties of _e1. That means that _e1 has to be some thing of type Geographical Position. _e1 would then be a thing of type Entry and of type Geographical Position. Which is a bit of a messy kind of thing. In particular since the id property of this thing is functional you would have a completely different Geo/Entry depending on what the id was. This is clearly very different from what we take the geo:x and geo:y properties to be referring to. > > -- > Roger Benningfield > From owner-atom-syntax@mail.imc.org Sat Jan 8 12: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 MAA20582 for ; Sat, 8 Jan 2005 12:37: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 j08HLS1d083551; Sat, 8 Jan 2005 09:21: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 j08HLSjW083550; Sat, 8 Jan 2005 09:21:28 -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 j08HLR82083480 for ; Sat, 8 Jan 2005 09:21:27 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 50031 messnum 3859469 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 8 Jan 2005 17:21:24 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.150?) (83.70.164.213) by mail08.svc.cra.dublin.eircom.net (qp 50031) with SMTP; 8 Jan 2005 17:21:24 -0000 Message-ID: <41E016A8.1090608@dehora.net> Date: Sat, 08 Jan 2005 17:21:44 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: RSS extensibility References: <1f2ed5cd05010714533f08c900@mail.gmail.com> <67018ACC-6105-11D9-8D42-003065EA6144@geckotribe.com> <1f2ed5cd05010801594d22db63@mail.gmail.com> <573271774.20050108120019@djpowell.net> In-Reply-To: <573271774.20050108120019@djpowell.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 David Powell wrote: > But you can't then expect to merge two different instances of the > entry under this model using simple RDF graph merging, because the > model is an over-simplification. > > Eg: If you merged: > > > http://123 > 2005-02-03 > 7 > > > and > > > http://123 > 2005-02-04 > 7.5 > > > ... you would get: > > > http://123 > 2005-02-03 > 2005-02-04 > 7.5 > 7 > > > Not very useful. That's a versioning problem. While I haven't found basic RDF to be useful for that, I could imagine finding an 60% solution with something like OWL. XML is of no help here. The usual answer is to use a version control system to record state in time series or allow update semantics to your persisted representations if you don't care about past state. Incidentally I do believe that being able to track state or trends in a time series fashion has commercial value in the syndication market. cheers Bill From owner-atom-syntax@mail.imc.org Sat Jan 8 12: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 MAA20916 for ; Sat, 8 Jan 2005 12:48: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 j08HWpge089253; Sat, 8 Jan 2005 09:32: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 j08HWpnl089252; Sat, 8 Jan 2005 09:32:51 -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 j08HWoxe089241 for ; Sat, 8 Jan 2005 09:32:50 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 88444 messnum 15254891 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 8 Jan 2005 17:32:47 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.150?) (83.70.164.213) by mail11.svc.cra.dublin.eircom.net (qp 88444) with SMTP; 8 Jan 2005 17:32:47 -0000 Message-ID: <41E01953.7030404@dehora.net> Date: Sat, 08 Jan 2005 17:33:07 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom WG Subject: Re: Hash for Links [Was: Re: Posted PaceEnclosuresAndPix] References: <1f2ed5cd050105162514f7773f@mail.gmail.com> <1f2ed5cd050106050455c75c9d@mail.gmail.com> <2bcdc7c405010609374df235f3@mail.gmail.com> In-Reply-To: <2bcdc7c405010609374df235f3@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 > hash="{generated_hash_value}" > hashalg="{uri_identifying_the_hash_algorithm_used" /> > > The hash and hashalg attributes would be optional but MUST appear together. > > Thoughts? (If we have more than two people respond favorably to this, > I'll write up a Pace for it) Seems like a good idea - would it be possible to move them into elements? How does that tee up for signing the markup, or just the hash+alg pair? cheers Bill From owner-atom-syntax@mail.imc.org Sat Jan 8 13: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 NAA22385 for ; Sat, 8 Jan 2005 13: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 j08IE2kA099161; Sat, 8 Jan 2005 10:14: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 j08IE24A099160; Sat, 8 Jan 2005 10:14: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-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 j08IDui0099103 for ; Sat, 8 Jan 2005 10:13:56 -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 j08IDvdt005737 for ; Sat, 8 Jan 2005 11:13:57 -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 <0IA000MI7FZ9BG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 08 Jan 2005 11:13:57 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA000080FZ88A@mail.sun.net> for atom-syntax@imc.org; Sat, 08 Jan 2005 11:13:57 -0700 (MST) Date: Sat, 08 Jan 2005 10:13:57 -0800 From: Tim Bray Subject: Re: Atom extensibility, RDF, and GRDDL In-reply-to: <41E008FB.7060609@dehora.net> To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Cc: "'Atom WG'" Message-id: <1088C779-61A1-11D9-A2C8-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=ISO-8859-1; format=flowed References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <41DF09C8.9090307@intertwingly.net> <41DF1641.7060405@franklinmint.fm> <41E008FB.7060609@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j08IE2i0099152 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Jan 8, 2005, at 8:23 AM, Bill de hÓra wrote: > My answer to this question is that Atom doesn't have a model in terms > of being able to talk about extension so there's no point discussing > it. Extensibility is probably out of scope for the format. I'm not going to let that go unchallenged. The ability to put your own markup in a feed entry and be confident that it will not cause receiving software to break, and that it will be there for receiving software that actually knows how to deal with it, is what many people describe using the word "extensibility". I think that Atom is, in a popular usage of the term (a large majority usage, I'd bet, but without backing statistics) extensible. The people who insist that you have to have to buy into a graph-theoretical KR model to be able to use the word "extensible" live in a universe that is self-consistent, but it's not the one where I work. -Tim From owner-atom-syntax@mail.imc.org Sat Jan 8 14:02: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 OAA24246 for ; Sat, 8 Jan 2005 14:02: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 j08InCeU008676; Sat, 8 Jan 2005 10:49: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 j08InCju008675; Sat, 8 Jan 2005 10:49: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 j08InBDo008668 for ; Sat, 8 Jan 2005 10:49: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 j08InFdt018529 for ; Sat, 8 Jan 2005 11:49:15 -0700 (MST) Received: from xpa-fe1 (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 <0IA000MX8HM2BG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 08 Jan 2005 11:49:15 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA00053IHM2DY@mail.sun.net> for atom-syntax@imc.org; Sat, 08 Jan 2005 11:49:14 -0700 (MST) Date: Sat, 08 Jan 2005 10:49:14 -0800 From: Tim Bray Subject: Closure on Extensibility & RDF To: "'Atom WG'" 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 [On behalf of Paul and myself:] The opinion has been forcefully expressed that Atom should adopt an extensibility framework based partly or wholly, directly or indirectly, on RDF. This idea is not unreasonable on the face of it. Thus, the time has now come to put this into a concrete proposal. Since we've talking about it for months, this shouldn't take long. Would the advocates of this view please, by Monday January 17th, bring the WG a proposal for its consideration. This could take one of these forms: - A Pace proposing extensibility-framework changes to the language of the format draft. (Rob/Joe, any chance of getting that -04 draft I know you're working on published Real Soon Now as a basis?) - A new Internet-Draft that co-exists with the existing Atom drafts that describes an extensibility framework. - Both. Note that if you do a Pace and it fails to obtain quick consensus, the ideas may fall by the wayside; on the other hand, if you do an I-D this may find a life of its own and wind its way to RFC-hood even if people in the Atom community remain unconvinced that they need it. Also, work on an I-D would be free of the distraction of Paul and I snarling at everyone to finish it up and ship it right now :) On the other hand, if the extensibility framework requires only a few simple additions and/or changes to the existing drafts, and there's a chance the WG will be OK with them, then that's probably a much better way to go. In any case, we've invested enough time arguing in the abstract. Discussions on this subject which are not framed in terms of specific language in specific documents will be ruled out of order by the co-chairs starting Monday January 17th. -Tim From owner-atom-syntax@mail.imc.org Sat Jan 8 14: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 OAA26281 for ; Sat, 8 Jan 2005 14: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 j08JXjSo022518; Sat, 8 Jan 2005 11:33: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 j08JXjIS022517; Sat, 8 Jan 2005 11:33:45 -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 j08JXebH022510 for ; Sat, 8 Jan 2005 11:33:40 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 39949 invoked by uid 17064); 8 Jan 2005 19:33:44 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.253.244.83]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 8 Jan 2005 19:33:44 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2787D98C-61AC-11D9-8C94-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: atom-owl@googlegroups.com, "'Atom WG'" From: Henry Story Subject: Re: Closure on Extensibility & RDF Date: Sat, 8 Jan 2005 20:33:20 +0100 To: Tim Bray X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Here is one suggestion I was thinking of to move along, quickly and seamlessly I hope. 1. Atom will have an associated machine readable OWL document that defines each of the objects and properties described in the Atom syntax spec, with language that mirrors that of the spec. 1.1 The IETF document is the final arbiter of any disputes 2. The Atom-OWL document will be placed at the namespace location of the Atom spec. 2.1 it will be retrievable in full by requesting that http location using the application/rdf+owl mime type 2.2 any of the atom properties or Entities definition will be retrievable by requesting the url of those entities in a web browser 2.3 a link to the atom-owl document will be placed from the IETF spec to the atom-owl document, specifying that a machine readable version of the spec is available at that location. 2.4 And vice versa the Atom-owl document will point to the IETF spec as the final arbiter of the meaning of the Atom-OWL document 3. Evolution of the Atom-OWL and Atom IETF specs 3.1 The aim is that any IETF Atom conformant document, be an RDF document as described by something like the transformation in [1] 3.1 during the evolution of the atom OWL development, the atom-owl document will be under the obligation to do anything it can within the syntax allowed by rdf and owl to map precisely the IETF document 3.2 If it is absolutely impossible for some aspect of atom-owl to map the IETF document, this should give some cause to think of revising the IETF spec so that such a mapping does become possible. This should be rare. 4. An Atom extended document is an Atom document with additional name spaced elements the whole of which can be mapped into an RDF graph. Henry Story [1] http://www.imc.org/atom-syntax/mail-archive/msg11850.html On 8 Jan 2005, at 19:49, Tim Bray wrote: > [On behalf of Paul and myself:] > > The opinion has been forcefully expressed that Atom should adopt an > extensibility framework based partly or wholly, directly or > indirectly, on RDF. This idea is not unreasonable on the face of it. > Thus, the time has now come to put this into a concrete proposal. > Since we've talking about it for months, this shouldn't take long. > > Would the advocates of this view please, by Monday January 17th, bring > the WG a proposal for its consideration. This could take one of these > forms: > > - A Pace proposing extensibility-framework changes to the language of > the format draft. (Rob/Joe, any chance of getting that -04 draft I > know you're working on published Real Soon Now as a basis?) > - A new Internet-Draft that co-exists with the existing Atom drafts > that describes an extensibility framework. > - Both. > > Note that if you do a Pace and it fails to obtain quick consensus, the > ideas may fall by the wayside; on the other hand, if you do an I-D > this may find a life of its own and wind its way to RFC-hood even if > people in the Atom community remain unconvinced that they need it. > Also, work on an I-D would be free of the distraction of Paul and I > snarling at everyone to finish it up and ship it right now :) > > On the other hand, if the extensibility framework requires only a few > simple additions and/or changes to the existing drafts, and there's a > chance the WG will be OK with them, then that's probably a much better > way to go. > > In any case, we've invested enough time arguing in the abstract. > Discussions on this subject which are not framed in terms of specific > language in specific documents will be ruled out of order by the > co-chairs starting Monday January 17th. > > -Tim > From owner-atom-syntax@mail.imc.org Sat Jan 8 14:53: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 OAA26833 for ; Sat, 8 Jan 2005 14:53: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 j08JiYER025360; Sat, 8 Jan 2005 11:44: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 j08JiYKA025359; Sat, 8 Jan 2005 11:44:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from priv-edtnes84.telusplanet.net (defout.telus.net [199.185.220.240]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j08JiYK5025297 for ; Sat, 8 Jan 2005 11:44:34 -0800 (PST) (envelope-from jeremy@jeremygray.ca) Received: from dora9 ([207.6.230.92]) by priv-edtnes84.telusplanet.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050108194426.HPZS29625.priv-edtnes84.telusplanet.net@dora9> for ; Sat, 8 Jan 2005 12:44:26 -0700 Reply-To: From: "Jeremy Gray" To: "'Atom WG'" Subject: RE: Atom extensibility, RDF, and GRDDL Date: Sat, 8 Jan 2005 11:44:25 -0800 Message-ID: <000601c4f5ba$76ee08d0$6400a8c0@dora9> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <1088C779-61A1-11D9-A2C8-000A95A51C9E@sun.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j08JiYK5025348 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Tim Bray > Sent: Saturday, January 08, 2005 10:14 AM > To: Bill de hÓra > Cc: 'Atom WG' > Subject: Re: Atom extensibility, RDF, and GRDDL --snip-- > The people who insist that you have to have to buy into a > graph-theoretical KR model to be able to use the word "extensible" live > in a universe that is self-consistent, but it's not the one where I > work. -Tim Having stepped back from both Atom and RDF a bit during the last few months, in part because I want to make sure I'm not wearing X-coloured glasses too often, but also because I find that I get too invested in and stressed out by some of the more heated discussions :), I've been trying to avoid jumping into this thread, but think its about time that I chime in and make my feelings known on this subject. It has long been apparent that the Atom community is not ready for RDF. While much of the industry is finally starting to see the benefits of semantic web technology, hence the emergence of terms like "semantic integration" (as an evolutionary step beyond current data integration techniques/tools/etc.), Atom and its community just aren't there yet. RDF is unfortunately one of those things that is difficult to understand until you've been bitten by one or more of the issues that it addresses and find yourself in a position to "get it". Once you need it, you "get it". Once you've "gotten it", you use it. Once you've "gotten it", it also becomes frustrating to watch other people suffer while not "getting it". You have the Atom community on one side, looking at RDF and thinking "the syntax is dumb, the model is unnecessary, XML is enough." Then you have the RDF pundits on the other side thinking "How can these guys not get it yet?" And this isn't meant to slight the Atom community in the least. The Atom community doesn't get it yet because it hasn't needed it yet, and unfortunately, as I mentioned before, RDF is one of those things that is hard to really "get" until you really need it [1]. And, as I've come to feel over the last few months, this can actually be seen as a _good thing_: Atom (or its successor) will adapt to (or simply somewhat align with) RDF when its community "gets it", which will occur if and only if / when and only when they _need_ it. The problem is that in the meantime most of the arguments from the RDF pundits are not only largely misunderstood or just seen as irrelevant, they act _against_ the intentions of the RDF pundits by coming off as the rantings of zealots of those want codified things that are obvious and who live in some strange world where everything is a graph. Not that this is the case, just that it ends up appearing as such. And I can safely say both of these because I am one of those zealots. :) With that in mind, here's what I would suggest: Henry, keep posting your periodic messages trying to softly help people understand RDF (and OWL, as many of your posts rely on it). Everyone seems to have missed how your most recent posts showed that an OWL reasoner and the rules provided to it would keep an application from even having to _implement_ logic to decide what entries should be merged or kept separate, and they all seemed to miss the fact that the included locations could be deemed equivalent and then merge together any information and/or relations ascribed to each of the two expressed locations. These are worthwhile things for people to understand, so keep at it. At least one of us needs to keep trying to help the community "get it", and in recent months I feel you have been doing the best job delivering that message in a clear, even-handed fashion. In general, the RDF pundits need to step back and recognize that until such time as the community has been bitten, needs, and subsequently "gets" the semweb, the best thing you can do is recognize that an RDF version of Atom will need to be created as a mapping, that mappings will also need to be created for any Atom extensions, and to spend your time helping Atom (and its extension authors) avoid doing things that will directly hamper RDF mapping efforts. Get working on those mappings, keep them in sync, keep the feedback loop going between the main effort and the mapping efforts, and work to create apps that will help the community edge closer to "getting it". Jeremy [1] This is worsened by the fact that the specification documents were largely HORRIBLE for several years, and because the intentions behind and syntax resulting from the RDF/XML effort is often misunderstood, but those are subjects for another place and time. :D From owner-atom-syntax@mail.imc.org Sat Jan 8 14:54: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 OAA26891 for ; Sat, 8 Jan 2005 14:54: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 j08Jm3bd026341; Sat, 8 Jan 2005 11: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 j08Jm3sQ026340; Sat, 8 Jan 2005 11:48:03 -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 j08Jm2wq026323 for ; Sat, 8 Jan 2005 11:48:02 -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 <20050108194801.MFHE20595.priv-edtnes40.telusplanet.net@dora9> for ; Sat, 8 Jan 2005 12:48:01 -0700 Reply-To: From: "Jeremy Gray" To: "'Atom WG'" Subject: RE: Atom extensibility Date: Sat, 8 Jan 2005 11:48:02 -0800 Message-ID: <000701c4f5ba$f6ade450$6400a8c0@dora9> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <41E00461.4000705@dehora.net> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j08Jm2wq026334 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Bill de hÓra > Sent: Saturday, January 08, 2005 8:04 AM > To: 'Atom WG' > Subject: Re: Atom extensibility --snip-- > I'm +1 on not requiring an RDF mapping for Atom. Those of us that like > to use RDF can figure out how to. +1 Jeremy From owner-atom-syntax@mail.imc.org Sat Jan 8 14:54: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 OAA26908 for ; Sat, 8 Jan 2005 14:54: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 j08JmnGa026551; Sat, 8 Jan 2005 11:48: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 j08JmnrS026550; Sat, 8 Jan 2005 11:48:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from priv-edtnes51.telusplanet.net (outbound04.telus.net [199.185.220.223]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j08Jmmh3026498 for ; Sat, 8 Jan 2005 11:48:48 -0800 (PST) (envelope-from jeremy@jeremygray.ca) Received: from dora9 ([207.6.230.92]) by priv-edtnes51.telusplanet.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050108194847.MDGG20702.priv-edtnes51.telusplanet.net@dora9> for ; Sat, 8 Jan 2005 12:48:47 -0700 Reply-To: From: "Jeremy Gray" To: "'Atom WG'" Subject: RE: Atom extensibility, RDF, and GRDDL Date: Sat, 8 Jan 2005 11:48:48 -0800 Message-ID: <000801c4f5bb$12299120$6400a8c0@dora9> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <41E00709.5020209@dehora.net> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j08Jmmh3026545 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Bill de hÓra > Sent: Saturday, January 08, 2005 8:15 AM > To: 'Atom WG' > Subject: Re: Atom extensibility, RDF, and GRDDL --snip-- > Sam I'm tempted to use the 'put in the implementors guide' - calling > GRDDL a standard is a reach imho. GRDDL is too from from being a standard to even merit mention (in the Atom spec) as a mapping mechanism between Atom and RDF. Jeremy From owner-atom-syntax@mail.imc.org Sat Jan 8 15:12: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 PAA28322 for ; Sat, 8 Jan 2005 15:12: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 j08K2UtU029957; Sat, 8 Jan 2005 12:02: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 j08K2UFr029956; Sat, 8 Jan 2005 12:02: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 j08K2THB029940 for ; Sat, 8 Jan 2005 12:02: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 1CnMms-0006gt-61; Sat, 08 Jan 2005 20:02:14 +0000 Message-ID: <41E03C53.1000701@franklinmint.fm> Date: Sat, 08 Jan 2005 15:02:27 -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 WG Subject: Re: Hash for Links [Was: Re: Posted PaceEnclosuresAndPix] References: <1f2ed5cd050105162514f7773f@mail.gmail.com> <1f2ed5cd050106050455c75c9d@mail.gmail.com> <2bcdc7c405010609374df235f3@mail.gmail.com> <41E01953.7030404@dehora.net> In-Reply-To: <41E01953.7030404@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: > > >> > hash="{generated_hash_value}" >> hashalg="{uri_identifying_the_hash_algorithm_used" /> >> >> The hash and hashalg attributes would be optional but MUST appear >> together. >> >> Thoughts? (If we have more than two people respond favorably to this, >> I'll write up a Pace for it) > > > > Seems like a good idea - would it be possible to move them into elements? Well, Content-Length lives in the attributes as "length", but I don't think we need to make a home for every HTTP header. Content-MD5 will work just fine; it would probably be wise to send a HEAD request before automatically downloading a giant mp3. Furthermore, you'll get a good enough identifier by concatenating the URI and the length. Something more accurate will require a HEAD request. Thirdly, there's absolutely no reason to have this in core. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Jan 8 15: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 PAA28610 for ; Sat, 8 Jan 2005 15: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 j08K2GQn029923; Sat, 8 Jan 2005 12:02: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 j08K2GDo029922; Sat, 8 Jan 2005 12:02:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from priv-edtnes56.telusplanet.net (outbound01.telus.net [199.185.220.220]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j08K2F20029893 for ; Sat, 8 Jan 2005 12:02:15 -0800 (PST) (envelope-from jeremy@jeremygray.ca) Received: from dora9 ([207.6.230.92]) by priv-edtnes56.telusplanet.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050108200214.NZCK11345.priv-edtnes56.telusplanet.net@dora9> for ; Sat, 8 Jan 2005 13:02:14 -0700 Reply-To: From: "Jeremy Gray" To: "'Atom WG'" Subject: RE: Closure on Extensibility & RDF Date: Sat, 8 Jan 2005 12:02:13 -0800 Message-ID: <000901c4f5bc$f31430e0$6400a8c0@dora9> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j08K2F20029917 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Tim Bray > Sent: Saturday, January 08, 2005 10:49 AM > To: 'Atom WG' > Subject: Closure on Extensibility & RDF > > [On behalf of Paul and myself:] > > The opinion has been forcefully expressed that Atom should adopt an > extensibility framework based partly or wholly, directly or indirectly, > on RDF. This idea is not unreasonable on the face of it. Thus, the > time has now come to put this into a concrete proposal. Since we've > talking about it for months, this shouldn't take long. > > Would the advocates of this view please, by Monday January 17th, bring > the WG a proposal for its consideration. This could take one of these > forms: Hehe. I finally post a long-winded message on the subject and then within moments I receive this in my inbox. I'll definitely give Tim's message a think, along with the replies to it, over the weekend. Have a good weekend everyone. Jeremy PS - Henry, Danny, Bill/Bill, et al - I know its been a while since I've been actively involved, but now looks like it would definitely be the right time, if any. If I can be of any assistance, whether in looking over draft text and/or playing devil's advocate in any conference calls, email threads, IRC chats, whatever, please feel free to get in touch. In the meantime, I'm going to think about a few extensibility experiments I have in mind, and will let you know if anything interesting comes of them. From owner-atom-syntax@mail.imc.org Sat Jan 8 15:42: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 PAA29738 for ; Sat, 8 Jan 2005 15:42: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 j08KTS8Y046576; Sat, 8 Jan 2005 12: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 j08KTSnw046575; Sat, 8 Jan 2005 12:29:28 -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 ([161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j08KTRTk045357 for ; Sat, 8 Jan 2005 12:29:28 -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 j08KS2lN013078; Sat, 8 Jan 2005 20:28:13 GMT In-Reply-To: <2bcdc7c405010609374df235f3@mail.gmail.com> References: <1f2ed5cd050105162514f7773f@mail.gmail.com> <1f2ed5cd050106050455c75c9d@mail.gmail.com> <2bcdc7c405010609374df235f3@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9-207347349; protocol="application/pkcs7-signature" Message-Id: Cc: Atom WG , Tim Bray From: Graham Subject: Re: Hash for Links [Was: Re: Posted PaceEnclosuresAndPix] Date: Sat, 8 Jan 2005 20:28:02 +0000 To: James Snell X-Mailer: Apple Mail (2.619) 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-207347349 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I require this functionality in . There is aboslutely no way I'm initiating 20 HTTP requests (even HEADs) each time the feed is reloaded. Graham --Apple-Mail-9-207347349 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 9w0BCQUxDxcNMDUwMTA4MjAyODAyWjAjBgkqhkiG9w0BCQQxFgQU/xJCjgHAGR7Sp1QFFQqbZvGU vPEweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEA3ETVTzJKDMJsI3K5Xt353HgG CcZf54henVlYJFcXRhnAN6VPYijq7FsEwDGg+CbvxIY2/hlDM3H8X7tPXfAYphOk7CnHIoaxRU44 JlJVtkg5LHQp43n8cVJOP+XUEGZOxKKdePXECTc3MZbMJB6HvO0YDbZoOaEQjhWcU5s6HPFr/Eft 7w7HwZQgibTo5JIwcm3X+qj93MMAZjF7yiOPIlUoPlVycdn/tdk857+G9jjfy/pT5b8Ffv7Ra3/4 6VtcrgdpYKxqJN153usC29SzPn/mHvTGzJ90HGcR/TyhUwLuK/LuXt14LwlKQYHfXYfK80MZG8l0 YVej42RV+8kjagAAAAAAAA== --Apple-Mail-9-207347349-- From owner-atom-syntax@mail.imc.org Sat Jan 8 15: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 PAA00173 for ; Sat, 8 Jan 2005 15: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 j08Kj0pT069218; Sat, 8 Jan 2005 12:45: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 j08Kj0Sd069217; Sat, 8 Jan 2005 12:45: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 j08KixCi069210 for ; Sat, 8 Jan 2005 12:44:59 -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 1CnNS1-00077o-JE; Sat, 08 Jan 2005 20:44:45 +0000 Message-ID: <41E0464A.6090802@franklinmint.fm> Date: Sat, 08 Jan 2005 15:44:58 -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: James Snell , Atom WG , Tim Bray Subject: Re: Hash for Links [Was: Re: Posted PaceEnclosuresAndPix] References: <1f2ed5cd050105162514f7773f@mail.gmail.com> <1f2ed5cd050106050455c75c9d@mail.gmail.com> <2bcdc7c405010609374df235f3@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 Graham wrote: > I require this functionality in . There is aboslutely > no way I'm initiating 20 HTTP requests (even HEADs) each time the feed > is reloaded. Can you explain why you would need to initiate HTTP requests for ? I don't understand. ... ... ... <img src="some.jpg"> Robert Sayre From owner-atom-syntax@mail.imc.org Sat Jan 8 16:00: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 QAA00372 for ; Sat, 8 Jan 2005 16:00: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 j08Kp6IW078705; Sat, 8 Jan 2005 12:51: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 j08Kp63N078703; Sat, 8 Jan 2005 12:51:06 -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 j08Kp5ne078591 for ; Sat, 8 Jan 2005 12:51:05 -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 j08Knt5K017390; Sat, 8 Jan 2005 20:49:56 GMT In-Reply-To: <41E0464A.6090802@franklinmint.fm> References: <1f2ed5cd050105162514f7773f@mail.gmail.com> <1f2ed5cd050106050455c75c9d@mail.gmail.com> <2bcdc7c405010609374df235f3@mail.gmail.com> <41E0464A.6090802@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-10-208660573; protocol="application/pkcs7-signature" Message-Id: Cc: James Snell , Atom WG , Tim Bray From: Graham Subject: Re: Hash for Links [Was: Re: Posted PaceEnclosuresAndPix] Date: Sat, 8 Jan 2005 20:49:55 +0000 To: Robert Sayre X-Mailer: Apple Mail (2.619) 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-208660573 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Well, for that example, it's not so necessary. But I've heard of one suggested usage being: Which would require reloading to maintain feature parity with non-external content. Graham --Apple-Mail-10-208660573 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 9w0BCQUxDxcNMDUwMTA4MjA0OTU2WjAjBgkqhkiG9w0BCQQxFgQUqhJo+xL4T9QQuwsl2rluE0Mz pXUweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAatwRmzZi3OchcnsEVWE9BRxS 7osX4+WZLvBMuBWVpuI3XI1F+RgqGE5GleMEc8WxhvRz8Vt3GSCAKKOyN25U7yO2ShZcxhRsM4bn zFm3k/Ko0JAmH0U7HKqIzFgLJG6teqGd1sX2SnT0+JOMl3/kPan5c+tHv8mhTaCb++iYl1YXkO2I HrATqYdZBZnNdXXLeJvSzbe8MCy7Am0/pTjhX7510FBOOLn2Q+fhnAeJLJKmRroggcAxFpSvinHn mO74kHfgr53vWrTF4TW+aBYTffvNL68167BXSRNNMUvqfIInpLjrIhvZT/JYqfJDJSFl6mffSPY4 GFAnyM0a0MwVFgAAAAAAAA== --Apple-Mail-10-208660573-- From owner-atom-syntax@mail.imc.org Sat Jan 8 16:04: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 QAA00580 for ; Sat, 8 Jan 2005 16:04: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 j08KohF3078455; Sat, 8 Jan 2005 12:50: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 j08KohrW078454; Sat, 8 Jan 2005 12:50:43 -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 j08KoeRm078408; Sat, 8 Jan 2005 12:50:41 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <2787D98C-61AC-11D9-8C94-000A95D9FA7A@bblfish.net> References: <2787D98C-61AC-11D9-8C94-000A95D9FA7A@bblfish.net> Date: Sat, 8 Jan 2005 12:50:42 -0800 To: Henry Story , Tim Bray From: Paul Hoffman / IMC Subject: Re: Closure on Extensibility & RDF Cc: atom-owl@googlegroups.com, "'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:33 PM +0100 1/8/05, Henry Story wrote: >Here is one suggestion I was thinking of to move along, quickly and >seamlessly I hope. All that seems fine, but your list is neither a Pace nor an Internet draft, and is therefore not in line with what Tim and I asked for. Given that you talk about an "IETF document", I am assuming that you intend to write the Internet Draft, yes? --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sat Jan 8 16:08: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 QAA00707 for ; Sat, 8 Jan 2005 16:08: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 j08KxMdj092608; Sat, 8 Jan 2005 12:59: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 j08KxMr9092607; Sat, 8 Jan 2005 12:59: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 j08KxLhe092593 for ; Sat, 8 Jan 2005 12:59: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 1CnNfv-0007EQ-IO; Sat, 08 Jan 2005 20:59:07 +0000 Message-ID: <41E049A8.1050903@franklinmint.fm> Date: Sat, 08 Jan 2005 15:59:20 -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: James Snell , Atom WG , Tim Bray Subject: Re: Hash for Links [Was: Re: Posted PaceEnclosuresAndPix] References: <1f2ed5cd050105162514f7773f@mail.gmail.com> <1f2ed5cd050106050455c75c9d@mail.gmail.com> <2bcdc7c405010609374df235f3@mail.gmail.com> <41E0464A.6090802@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 Graham wrote: > Well, for that example, it's not so necessary. But I've heard of one > suggested usage being: > > > > Which would require reloading to maintain feature parity with > non-external content. http://atompub.org/2004/10/20/draft-ietf-atompub-format-03.html#rfc.section.5.10.2 "If the value of type begins with "text/" or ends with "+xml", the content SHOULD be local; that is to say, no "src" attribute should be provided." If you want to suggest language that describes the bad things that could happen when people ignore that recommendation, I would be happy to include it. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Jan 8 16:35: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 QAA01824 for ; Sat, 8 Jan 2005 16: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 j08LKt30026311; Sat, 8 Jan 2005 13:20: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 j08LKt2M026310; Sat, 8 Jan 2005 13:20:55 -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 j08LKs4k026082 for ; Sat, 8 Jan 2005 13:20:55 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so669360rnz for ; Sat, 08 Jan 2005 13:20: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=N8KyV/Xqk7GtvVWlvKKgtfovyJ2exn5hH/kn7YPSQ5n6l9fWuZUlPkt2QjQ3+LQRfg0nw6Axe1/L5U5dw4WPAfHF/qrw1fGpaWg1kt9BqjO7LzpU/NbIrpMP0m6vjlNUvd3ko8Ro3GW2WyjAi4qYZbg7OPw/DHN2ec5k97flgfg= Received: by 10.38.179.12 with SMTP id b12mr29334rnf; Sat, 08 Jan 2005 13:20:54 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sat, 8 Jan 2005 13:20:54 -0800 (PST) Message-ID: <1f2ed5cd05010813204e0383d6@mail.gmail.com> Date: Sat, 8 Jan 2005 22:20:54 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: Atom extensibility, RDF, and GRDDL Cc: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom WG In-Reply-To: <1088C779-61A1-11D9-A2C8-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <41DF09C8.9090307@intertwingly.net> <41DF1641.7060405@franklinmint.fm> <41E008FB.7060609@dehora.net> <1088C779-61A1-11D9-A2C8-000A95A51C9E@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j08LKt4k026301 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sat, 08 Jan 2005 10:13:57 -0800, Tim Bray wrote: > > On Jan 8, 2005, at 8:23 AM, Bill de hÓra wrote: > > > My answer to this question is that Atom doesn't have a model in terms > > of being able to talk about extension so there's no point discussing > > it. Extensibility is probably out of scope for the format. > > I'm not going to let that go unchallenged. The ability to put your own > markup in a feed entry and be confident that it will not cause > receiving software to break, and that it will be there for receiving > software that actually knows how to deal with it, is what many people > describe using the word "extensibility". I think that Atom is, in a > popular usage of the term (a large majority usage, I'd bet, but without > backing statistics) extensible. FOLDOC [1] has: [[ extensible Said of a system (e.g., program, file format, programming language, protocol, etc.) designed to easily allow the addition of new features at a later date, e.g. through the use of hooks, an API or plug-ins. ]] Unless XML and XML accessories have mangled the English language totally beyond recognition, that seems a reasonable definition. > The people who insist that you have to have to buy into a > graph-theoretical KR model to be able to use the word "extensible" live > in a universe that is self-consistent, but it's not the one where I > work. -Tim Nor I. (I presume anyway - I've never encountered any of those people). Cheers, Danny. [1] http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=extensible&action=Search -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Jan 8 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 RAA02593 for ; Sat, 8 Jan 2005 17:00: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 j08Lmm6I063941; Sat, 8 Jan 2005 13: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 j08LmmAk063940; Sat, 8 Jan 2005 13:48:48 -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 j08LmlfE063910 for ; Sat, 8 Jan 2005 13:48:48 -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 <20050108214844.XLRN23615.fed1rmmtao04.cox.net@[192.168.0.100]>; Sat, 8 Jan 2005 16:48:44 -0500 In-Reply-To: <1f2ed5cd0501080221230cfb4@mail.gmail.com> References: <1f2ed5cd05010705487956cbbf@mail.gmail.com> <1f2ed5cd0501080221230cfb4@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <13379A72-61BF-11D9-ACB1-000D93324AD6@gbiv.com> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org From: "Roy T. Fielding" Subject: Re: RSS extensibility Date: Sat, 8 Jan 2005 13:48:47 -0800 To: Danny Ayers X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 8, 2005, at 2:21 AM, Danny Ayers wrote: > Perhaps I wasn't clear enough. XML has containment. Individual > specifications may assign it semantics. RDF/XML assigns it semantics > corresponding to the RDF model. Without either the individual > specification's definition, or a generalised interpretation like > RDF/XML's all you have is syntax featuring containment. No, you were clear, it was just that your statement is false. Element containment is a semantic that almost all XML data formats obey. In fact, the only one I know of that doesn't is RDF/XML. No other format needs to assign those semantics to XML. > But XML containment can only express tree structures. To express graph > structures, the containment must somehow be violated. RDF is a graph. And Atom feed is a tree. If we try to express tree structures with a graph language, we create complexity that would not exist with a tree language because a tree already has constraints built-in. The extra constraints that RDF needs in order to dig itself out of its own hole are not necessary for languages that avoid the hole in the first place. >> I do hope that folks understand that the relationship should be >> obvious to anyone who does not >> work in a language that is as perversely non-mark-up as RDF/XML. > > Well there you have it - it is possible to design XML languages that > are perverse. So we can't rely on everyone following the 'obvious' > relationship pattern. Making it explicit should help prevent > misinterpretation. On the contrary, we can safely ignore languages that are perverse in their use of XML because those languages will have to define their own islands of semantics which are self-contained and irrelevant to their surroundings. Other languages do not have to understand the non-containment semantics of rdf:Description because those semantics are defined by RDF/XML regardless of what other language it may be embedded within. ....Roy From owner-atom-syntax@mail.imc.org Sat Jan 8 17:04: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 RAA02749 for ; Sat, 8 Jan 2005 17:04: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 j08LslmJ065383; Sat, 8 Jan 2005 13:54: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 j08LslFV065382; Sat, 8 Jan 2005 13:54:47 -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 j08LslW1065365 for ; Sat, 8 Jan 2005 13:54:47 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 51629 invoked by uid 17064); 8 Jan 2005 21:54:51 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.251.47.201]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 8 Jan 2005 21:54:51 -0000 In-Reply-To: References: <2787D98C-61AC-11D9-8C94-000A95D9FA7A@bblfish.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-owl@googlegroups.com, "'Atom WG'" From: Henry Story Subject: Re: Closure on Extensibility & RDF Date: Sat, 8 Jan 2005 22:54:28 +0100 To: Paul Hoffman / IMC X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The IETF document I mentioned is the one this mailing list is working on developing. The four points I listed are starting points for a couple of small additions to the Atom IETF document and their relation to a to be written OWL Ontology. There are I am sure people more familiar with the ins and outs of this standards process that will know how to turn that general idea into more specific and acceptable proposals. Henry On 8 Jan 2005, at 21:50, Paul Hoffman / IMC wrote: > At 8:33 PM +0100 1/8/05, Henry Story wrote: >> Here is one suggestion I was thinking of to move along, quickly and >> seamlessly I hope. > > All that seems fine, but your list is neither a Pace nor an Internet > draft, and is therefore not in line with what Tim and I asked for. > Given that you talk about an "IETF document", I am assuming that you > intend to write the Internet Draft, yes? > > --Paul Hoffman, Director > --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sat Jan 8 17:12: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 RAA02972 for ; Sat, 8 Jan 2005 17:12: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 j08M3SPh067558; Sat, 8 Jan 2005 14:03: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 j08M3S4L067557; Sat, 8 Jan 2005 14:03:28 -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 j08M3ReZ067546 for ; Sat, 8 Jan 2005 14:03:28 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so670124rnz for ; Sat, 08 Jan 2005 14:03: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:to:subject:cc:mime-version:content-type:content-transfer-encoding; b=i+VspdPcQCCZokodsSq2hJ0HpWWg1nxraQQbV1gX3Kop6BHd3ftYUzmgpCaGclObKlENEVDv5/83CaP4uWxk3Kfj9vR0Hoet1XXL65dmDYPpYeAjJQlNgYpV60vHfz3HNWanaMVyhuaUP/JlO+FgTca6Z/bVTU45vsJ7SVb8BBA= Received: by 10.38.179.12 with SMTP id b12mr38115rnf; Sat, 08 Jan 2005 14:03:30 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sat, 8 Jan 2005 14:03:30 -0800 (PST) Message-ID: <1f2ed5cd0501081403144e7bc6@mail.gmail.com> Date: Sat, 8 Jan 2005 23:03:30 +0100 From: Danny Ayers Reply-To: Danny Ayers To: phoffman@imc.org, Tim.Bray@Sun.COM, rubys@intertwingly.net Subject: Comment on process Cc: atom-syntax@imc.org 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'm not going to argue the point here any further, but feel something has to be said. I am optimistic a compromise on the extensibility/RDF issue can be reached in the given time frame, but find the imposition of such a short period a bit extreme. It isn't that there hasn't been considerable work on RDF-compatibility, that side's potentially trivial (use RDF/XML!), it's the production of a compromise everyone is comfortable with. I doubt anyone reading Tim's recent posts on the subject of extensibility could come to any conclusion other than that he is vehemently opposed to any inclusion of anything associated with RDF in the core specification. I certainly don't mean any personal criticism on this point, only that, as I have said before, I think it's important that the project is not only open but seen to be open. I am sure everything is above board, it's only an unfortunate coincidence, but setting this cutoff on a point on which one of the chairs has taken a strong viewpoint doesn't look good. Isn't this the first time a strict deadline has been imposed for proposals for any set of features? (Aside of course from the name). No-one gains anything from overly protracted discussion. But I don't seen any extraordinary circumstances that might justify the imposition of cloture. Is there something related to the (still unexplained) "deadline" mentioned in Tim's recent post? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Jan 8 17:26: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 RAA03520 for ; Sat, 8 Jan 2005 17:26: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 j08MEAKA070184; Sat, 8 Jan 2005 14:14: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 j08MEAZJ070182; Sat, 8 Jan 2005 14:14:10 -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 j08ME9cX070158 for ; Sat, 8 Jan 2005 14:14:09 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so670281rnz for ; Sat, 08 Jan 2005 14:14: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:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ftl4qs7+TZaR9gT66LctUPxOKQTQu+ZN3iW9En4KlIVB6SDQMdCprSnlH4mLzNyJgqfTzONK2ubJbxnT6YECC+Z67rmxaDRgtNAXpdY0RdU/fgGZlUYNf+r3+m6gfL9ERfg2zrWSrhdc+3owmDPPDDmvd9vn/VIa9+2cui0GrCc= Received: by 10.38.179.12 with SMTP id b12mr40421rnf; Sat, 08 Jan 2005 14:14:11 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sat, 8 Jan 2005 14:14:11 -0800 (PST) Message-ID: <1f2ed5cd05010814142402615a@mail.gmail.com> Date: Sat, 8 Jan 2005 23:14:11 +0100 From: Danny Ayers Reply-To: Danny Ayers To: "Roy T. Fielding" Subject: Re: RSS extensibility Cc: atom-syntax@imc.org In-Reply-To: <13379A72-61BF-11D9-ACB1-000D93324AD6@gbiv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd05010705487956cbbf@mail.gmail.com> <1f2ed5cd0501080221230cfb4@mail.gmail.com> <13379A72-61BF-11D9-ACB1-000D93324AD6@gbiv.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 8 Jan 2005 13:48:47 -0800, Roy T. Fielding wrote: > On Jan 8, 2005, at 2:21 AM, Danny Ayers wrote: > > Perhaps I wasn't clear enough. XML has containment. Individual > > specifications may assign it semantics. RDF/XML assigns it semantics > > corresponding to the RDF model. Without either the individual > > specification's definition, or a generalised interpretation like > > RDF/XML's all you have is syntax featuring containment. > > No, you were clear, it was just that your statement is false. > Element containment is a semantic that almost all XML data formats obey. > In fact, the only one I know of that doesn't is RDF/XML. No other > format needs to assign those semantics to XML. > > > But XML containment can only express tree structures. To express graph > > structures, the containment must somehow be violated. RDF is a graph. > > And Atom feed is a tree. If we try to express tree structures with a > graph language, we create complexity that would not exist with a tree > language because a tree already has constraints built-in. The extra > constraints that RDF needs in order to dig itself out of its own hole > are not necessary for languages that avoid the hole in the first place. > > >> I do hope that folks understand that the relationship should be > >> obvious to anyone who does not > >> work in a language that is as perversely non-mark-up as RDF/XML. > > > > Well there you have it - it is possible to design XML languages that > > are perverse. So we can't rely on everyone following the 'obvious' > > relationship pattern. Making it explicit should help prevent > > misinterpretation. > > On the contrary, we can safely ignore languages that are perverse > in their use of XML because those languages will have to define > their own islands of semantics which are self-contained and > irrelevant to their surroundings. Other languages do not have > to understand the non-containment semantics of rdf:Description > because those semantics are defined by RDF/XML regardless of > what other language it may be embedded within. Earlier you said: [[ While I don't see any reason not to make XML's mark-up relations explicit in the specification, I do hope that folks understand that the relationship should be obvious to anyone who does not work in a language that is as perversely non-mark-up as RDF/XML. ]] While I disagree with some of the other points you have made (probably none of the facts, more the general focus), I believe the first part of this sentence is the issue that most directly affects Atom, and on that I agree. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Jan 8 17:35: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 RAA03768 for ; Sat, 8 Jan 2005 17:35: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 j08MOGNc073463; Sat, 8 Jan 2005 14:24: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 j08MOGGn073462; Sat, 8 Jan 2005 14:24:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from lakermmtao05.cox.net (lakermmtao05.cox.net [68.230.240.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j08MOEpj073454 for ; Sat, 8 Jan 2005 14:24:15 -0800 (PST) (envelope-from sah@428cobrajet.net) Received: from A31P ([68.100.55.187]) by lakermmtao05.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050108222413.MSVO16431.lakermmtao05.cox.net@A31P>; Sat, 8 Jan 2005 17:24:13 -0500 From: "Scott Hollenbeck" To: "'Danny Ayers'" Cc: Subject: RE: Comment on process Date: Sat, 8 Jan 2005 17:26: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.6353 In-Reply-To: <1f2ed5cd0501081403144e7bc6@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcT1zf5+i9QnI907RHyOUCSjICzqGgAAgsXA Message-Id: <20050108222413.MSVO16431.lakermmtao05.cox.net@A31P> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > No-one gains anything from overly protracted discussion. But > I don't seen any extraordinary circumstances that might > justify the imposition of cloture. Is there something related > to the (still unexplained) "deadline" mentioned in Tim's recent post? I'm not sure that I understand why you believe the "deadline" is unexplained. Take a look at the charter for this working group: http://www.ietf.org/html.charters/atompub-charter.html There are goals and milestones identified with due dates. The working group chairs have an obligation to keep the working group on track to meet those milestones. They can set interim goals for smaller tasks if they feel it's necessary. Given that the goals and milestones were agreed upon as part of the creation of this working group, what's not clear? -Scott- (atompub area advisor) From owner-atom-syntax@mail.imc.org Sat Jan 8 17: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 RAA04297 for ; Sat, 8 Jan 2005 17:46: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 j08McCpF076378; Sat, 8 Jan 2005 14:38: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 j08McCV1076377; Sat, 8 Jan 2005 14:38:12 -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 j08McB95076320; Sat, 8 Jan 2005 14:38:11 -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 <20050108223810.YJMT27771.fed1rmmtao08.cox.net@[192.168.0.100]>; Sat, 8 Jan 2005 17:38:10 -0500 In-Reply-To: <1f2ed5cd0501081403144e7bc6@mail.gmail.com> References: <1f2ed5cd0501081403144e7bc6@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: rubys@intertwingly.net, Tim.Bray@Sun.COM, phoffman@imc.org, atom-syntax@imc.org From: "Roy T. Fielding" Subject: Re: Comment on process Date: Sat, 8 Jan 2005 14:38:13 -0800 To: Danny Ayers X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 8, 2005, at 2:03 PM, Danny Ayers wrote: > No-one gains anything from overly protracted discussion. But I don't > seen any extraordinary circumstances that might justify the imposition > of cloture. Is there something related to the (still unexplained) > "deadline" mentioned in Tim's recent post? Tim already said (before yet another round of RDF waffling started) that the chairs were seeking to produce a final draft. What he did was extend his own deadline to give you time to make a concrete, forward proposal on what needs to be done, either in a PACE (like everyone else) or in a separate draft. If you can't do that in four days then it isn't going in the next draft, which is the only horizon that chairs have control over. As far as process goes, Tim (and Paul) have been exceedingly kind. I would have simply said "Put up or shut up" some six months ago and further discussion would be out of order until such time as there is a concrete proposal to be discussed. IETF WGs move forward on the basis of rough consensus and running code. ....Roy From owner-atom-syntax@mail.imc.org Sat Jan 8 18:01: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 SAA04799 for ; Sat, 8 Jan 2005 18:01: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 j08MrXgD080396; Sat, 8 Jan 2005 14:53: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 j08MrXcC080395; Sat, 8 Jan 2005 14:53:33 -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 j08MrPxZ080354; Sat, 8 Jan 2005 14:53:29 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1f2ed5cd0501081403144e7bc6@mail.gmail.com> References: <1f2ed5cd0501081403144e7bc6@mail.gmail.com> Date: Sat, 8 Jan 2005 14:53:28 -0800 To: Danny Ayers , Tim.Bray@Sun.COM, rubys@intertwingly.net From: Paul Hoffman / IMC Subject: Re: Comment on process Cc: atom-syntax@imc.org 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:03 PM +0100 1/8/05, Danny Ayers wrote: >I am optimistic a compromise on the extensibility/RDF issue can be >reached in the given time frame, Good! > but find the imposition of such a >short period a bit extreme. The WG has been discussing this for *months*. The fact that the chairs have put an end-point on those months does not make the total time a "short period". Given the amount of discussion so far, do you really believe it is impossible to put together a concrete proposal either as a Pace or as an Internet Draft in a week? If so, that indicates that the problem is not describable enough for inclusion in a standard. Tim and I believe that there are some people in the WG who don't believe that, but we need to see proof. >I doubt anyone reading Tim's recent posts on the subject of >extensibility could come to any conclusion other than that he is >vehemently opposed to any inclusion of anything associated with RDF in >the core specification. Tim has most recently said "The opinion has been forcefully expressed that Atom should adopt an extensibility framework based partly or wholly, directly or indirectly, on RDF. This idea is not unreasonable on the face of it." I cannot parse that in any way that leads to a belief that he is "vehemently opposed" so such inclusion; the opposite seems much more true. What he and I are asking for is to finally finish. We've talked enough; give a proposal for how to move forward so the WG can come to consensus. >Isn't this the first time >a strict deadline has been imposed for proposals for any set of >features? (Aside of course from the name). Not at all. It has happened many times in the past. Each time we solicit to close issues, there is a (usually implicit) deadline for responding to that call. This is no different, except that we still don't have a Pace or Internet Draft to work from. So, the chairs have two choices in order to come to closure soon on the discussion that is of interest to everyone here: a) Say "there is still no proposal, so closure is reached in the negative" b) Say "we will soon reach closure in the negative unless someone posts a concrete proposal we can find consensus around. At least to me, (b) seems like the better option, yes? >No-one gains anything from overly protracted discussion. Fully agree. > But I don't >seen any extraordinary circumstances that might justify the imposition >of cloture. Agree. That's why we are asking for a proposal that we can discuss. > Is there something related to the (still unexplained) >"deadline" mentioned in Tim's recent post? See Scott's response, with which I fully agree. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sat Jan 8 18:02: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 SAA04817 for ; Sat, 8 Jan 2005 18:02: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 j08MrTJi080364; Sat, 8 Jan 2005 14:53: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 j08MrTXK080363; Sat, 8 Jan 2005 14:53:29 -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 j08MrPxX080354; Sat, 8 Jan 2005 14:53:26 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <2787D98C-61AC-11D9-8C94-000A95D9FA7A@bblfish.net> Date: Sat, 8 Jan 2005 14:35:21 -0800 To: Henry Story From: Paul Hoffman / IMC Subject: Re: Closure on Extensibility & RDF Cc: atom-owl@googlegroups.com, "'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:54 PM +0100 1/8/05, Henry Story wrote: >The IETF document I mentioned is the one this mailing list is >working on developing. Then you didn't understand Tim's message. He meant a *new* Internet draft, not a change to the current draft (unless the change is a few sentences). From your list of changes, it doesn't seem like it is just a few sentences, so you need to submit a separate Internet Draft, initially as an individual submission. If the WG agrees that it should be a WG work item, it will change into one; otherwise, you can pursue it as an individual document, probably still discussing it on this mailing list. > The four points I listed are starting points for a couple of small >additions to the Atom IETF document and their relation to a to be >written OWL Ontology. There are I am sure people more familiar with >the ins and outs of this standards process that will know how to >turn that general idea into more specific and acceptable proposals. See Tim's message. You do this by creating either a detailed Pace or a complete Internet Draft. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sat Jan 8 18:20: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 SAA06451 for ; Sat, 8 Jan 2005 18:20: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 j08N6kJR083461; Sat, 8 Jan 2005 15:06: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 j08N6k2L083460; Sat, 8 Jan 2005 15:06:46 -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 j08N6kpb083445 for ; Sat, 8 Jan 2005 15:06:46 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 1762 invoked by uid 17064); 8 Jan 2005 23:06:50 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.253.244.242]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 8 Jan 2005 23:06:50 -0000 In-Reply-To: References: <2787D98C-61AC-11D9-8C94-000A95D9FA7A@bblfish.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-owl@googlegroups.com, "'Atom WG'" From: Henry Story Subject: Re: Closure on Extensibility & RDF Date: Sun, 9 Jan 2005 00:06:27 +0100 To: Paul Hoffman / IMC X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The "internet draft" I want to propose is an OWL document. I can get this out tomorrow. It will essentially say everything the current Atom OWL spec says, but in machine readable form. All that is required then is that the Atom IETF document this working group is working on have some language describing its relation to the OWL document. This need not be a very big change to the current document. I believe it could be done in a few sentences taking my first proposal as a guide. If anyone has some good ideas on where it would be best to change the language, please help me along and write that out. I can do with all the help out there :-) Understand that all I am proposing is a machine readable rewriting of what the current Atom spec says. That is most of what there is to it. The rest is just asking for a little good will. Yours sincerely, Henry Story http://bblfish.net/blog/ On 8 Jan 2005, at 23:35, Paul Hoffman / IMC wrote: > > At 10:54 PM +0100 1/8/05, Henry Story wrote: >> The IETF document I mentioned is the one this mailing list is working >> on developing. > > Then you didn't understand Tim's message. He meant a *new* Internet > draft, not a change to the current draft (unless the change is a few > sentences). From your list of changes, it doesn't seem like it is just > a few sentences, so you need to submit a separate Internet Draft, > initially as an individual submission. If the WG agrees that it should > be a WG work item, it will change into one; otherwise, you can pursue > it as an individual document, probably still discussing it on this > mailing list. > >> The four points I listed are starting points for a couple of small >> additions to the Atom IETF document and their relation to a to be >> written OWL Ontology. There are I am sure people more familiar with >> the ins and outs of this standards process that will know how to turn >> that general idea into more specific and acceptable proposals. > > See Tim's message. You do this by creating either a detailed Pace or a > complete Internet Draft. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-atom-syntax@mail.imc.org Sat Jan 8 18: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 SAA06727 for ; Sat, 8 Jan 2005 18: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 j08NFvVe085550; Sat, 8 Jan 2005 15:15: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 j08NFvw4085549; Sat, 8 Jan 2005 15:15:57 -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 j08NFuPQ085533 for ; Sat, 8 Jan 2005 15:15:56 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 8498 invoked by uid 17064); 8 Jan 2005 23:16:01 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.253.244.242]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 8 Jan 2005 23:16:01 -0000 In-Reply-To: References: <2787D98C-61AC-11D9-8C94-000A95D9FA7A@bblfish.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <357823C8-61CB-11D9-8C94-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: atom-owl@googlegroups.com, "'Atom WG'" From: Henry Story Subject: Re: Closure on Extensibility & RDF Date: Sun, 9 Jan 2005 00:15:38 +0100 To: Paul Hoffman / IMC X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 9 Jan 2005, at 00:06, Henry Story wrote: > > The "internet draft" I want to propose is an OWL document. I can get > this out tomorrow. It will essentially say everything the current Atom > OWL spec says, Sorry it is past midnight here at I am typing a little fast. I meant "It will essentially say everything the current Atom spec[1] says," [1] http://ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub- format-03.txt > but in machine readable form. > > All that is required then is that the Atom IETF document this working > group is working on have some language describing its relation to the > OWL document. This need not be a very big change to the current > document. I believe it could be done in a few sentences taking my > first proposal as a guide. If anyone has some good ideas on where it > would be best to change the language, please help me along and write > that out. I can do with all the help out there :-) > > Understand that all I am proposing is a machine readable rewriting of > what the current Atom spec says. That is most of what there is to it. > The rest is just asking for a little good will. > > Yours sincerely, > > Henry Story > http://bblfish.net/blog/ > > > On 8 Jan 2005, at 23:35, Paul Hoffman / IMC wrote: > >> >> At 10:54 PM +0100 1/8/05, Henry Story wrote: >>> The IETF document I mentioned is the one this mailing list is >>> working on developing. >> >> Then you didn't understand Tim's message. He meant a *new* Internet >> draft, not a change to the current draft (unless the change is a few >> sentences). From your list of changes, it doesn't seem like it is >> just a few sentences, so you need to submit a separate Internet >> Draft, initially as an individual submission. If the WG agrees that >> it should be a WG work item, it will change into one; otherwise, you >> can pursue it as an individual document, probably still discussing it >> on this mailing list. >> >>> The four points I listed are starting points for a couple of small >>> additions to the Atom IETF document and their relation to a to be >>> written OWL Ontology. There are I am sure people more familiar with >>> the ins and outs of this standards process that will know how to >>> turn that general idea into more specific and acceptable proposals. >> >> See Tim's message. You do this by creating either a detailed Pace or >> a complete Internet Draft. >> >> --Paul Hoffman, Director >> --Internet Mail Consortium >> > From owner-atom-syntax@mail.imc.org Sat Jan 8 18: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 SAA06955 for ; Sat, 8 Jan 2005 18: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 j08NPLT4088409; Sat, 8 Jan 2005 15:25: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 j08NPLTX088408; Sat, 8 Jan 2005 15:25:21 -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 j08NPI2Z088399; Sat, 8 Jan 2005 15:25:18 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <2787D98C-61AC-11D9-8C94-000A95D9FA7A@bblfish.net> Date: Sat, 8 Jan 2005 15:25:17 -0800 To: Henry Story From: Paul Hoffman / IMC Subject: Re: Closure on Extensibility & RDF Cc: atom-owl@googlegroups.com, "'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 12:06 AM +0100 1/9/05, Henry Story wrote: >The "internet draft" I want to propose is an OWL document. I can get >this out tomorrow. It will essentially say everything the current >Atom OWL spec says, but in machine readable form. An OWL document is not an Internet Draft. If you cannot create an Internet Draft, please find someone who agrees with your desires to help you. >All that is required then is that the Atom IETF document this >working group is working on have some language describing its >relation to the OWL document. That should be included in your Internet Draft. > This need not be a very big change to the current document. That remains to be seen. The best way we can see it is in your Internet Draft. Clearly, if it is a small change and the WG wants to use it, it can be folded into the main document before we send it to the IETF. > I believe it could be done in a few sentences taking my first >proposal as a guide. Great! Let's see them. > If anyone has some good ideas on where it would be best to change >the language, please help me along and write that out. That is actually the least important point in your proposal, and the easiest to take care of late in the process if the WG agrees to the incorporation. If the WG doesn't agree to the incorporation, it isn't needed at all in your Internet Draft. >I can do with all the help out there :-) So can we all... >Understand that all I am proposing is a machine readable rewriting >of what the current Atom spec says. In order for us to verify that statement, we need to see the rewriting, and we need to hear from a few people who understand OWL saying "yup, that exactly matches what is in the format draft". > That is most of what there is to it. The rest is just asking for a >little good will. Fully disagree. The rest is the WG coming to consensus on whether or not we want this as part of the baseline spec. Given this WG's propensity to disagree about most things XML and RDF, assuming that will come easily is not based on even a casual reading of the mailing list. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sat Jan 8 18:50: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 SAA07651 for ; Sat, 8 Jan 2005 18:50: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 j08NeBvR091402; Sat, 8 Jan 2005 15: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 j08NeBvk091401; Sat, 8 Jan 2005 15:40:11 -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 j08NeBTZ091365 for ; Sat, 8 Jan 2005 15:40: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 <2005010823401001200p4u62e>; Sat, 8 Jan 2005 23:40:11 +0000 Date: Sat, 8 Jan 2005 16:40:09 -0700 Subject: Re: RSS extensibility 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: <1f2ed5cd05010801594d22db63@mail.gmail.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 Saturday, January 8, 2005, at 02:59 AM, Danny Ayers wrote: > Say your system is aggregating material from two sensors, and you get > the following, one from each: > > > http://123 > 2005-02-02 > 10.1 > 57.3 > > > > http://123 > 2005-02-03 > 7 > > > It isn't clear how these should be merged - does the entry with the > later date replace the earlier one? The (presumably) desired behaviour > is for the geo+seismo properties all to appear as elements under > (properties of) the entry. Mapping syntax to a model can help decide > what to do *in the general case* rather than per-extension. As it > happens, RSS/RDF would only go part of the way with something like > this - you'd get the desired merged entry, but with two dates. Unless we have a way to track which parts of an entry came from which source (which it sounds like we don't yet), I'd have to say that merging entries seems like a bad idea. Perhaps a future version of Atom developed after methods of doing that have been refined can be made to take advantage of them. Your example does clearly show the value of being able to merge entries, but as far as we are from being able to do it properly (in the general case, that is--one could certainly write application specific code to merge the entries in the example), I think we should drop it as a goal for now. I could see sense in wanting to put both of these entries into a single feed as a means of collecting their data (in which case, the question arises, would that violate the "unique ID' restriction? are they both the same entry, and thus able to have the same ID?), but that's probably as far as we can go. >> geox = GetElementContent("/geo:x"); >> geoy = GetElementContent("/geo:y"); >> magnitude = GetElementContent("/seismo:magnitude"); >> >> geox = GetAttribute("/geo:coords/@x"); >> geox = GetAttribute("/geo:coords/@y"); >> magnitude = GetElementContent("/seismo:magnitude"); > > Yes, trivially different, two extra lines of code. Potentially for > every developer, for every extension. I think we're looking at this differently--I see two DIFFERENT lines of code, not two EXTRA lines of code. Either the geo extension puts x and y into attributes, or it puts them into child elements--the way that particular extension works isn't going to vary from feed to feed, and thus will require the same amount of code whichever way it works. Am I missing something? Antone From owner-atom-syntax@mail.imc.org Sat Jan 8 18:59: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 SAA08212 for ; Sat, 8 Jan 2005 18:59: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 j08Nn5pC093455; Sat, 8 Jan 2005 15:49: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 j08Nn5Ee093441; Sat, 8 Jan 2005 15:49: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 j08NmsdJ093376 for ; Sat, 8 Jan 2005 15:49:04 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 29663 invoked by uid 17064); 8 Jan 2005 23:48:59 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.253.244.242]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 8 Jan 2005 23:48:59 -0000 In-Reply-To: References: <2787D98C-61AC-11D9-8C94-000A95D9FA7A@bblfish.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-owl@googlegroups.com, "'Atom WG'" From: Henry Story Subject: Re: Closure on Extensibility & RDF Date: Sun, 9 Jan 2005 00:48:33 +0100 To: Paul Hoffman / IMC X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I can't do everything simultaneously. Tomorrow I will give you a first version of an OWL document that will map the current atom spec. Can you give me the current namespace for the draft atom spec I am supposed to be working to? This is so the atom OWL document can describe the properties of the draft atom spec. The url of the location of the directory of the draft spec will probably do. Then I can define the properties of atom:content using the full url say http://purl.org/atom/#content When someone clicks on that link with a browser that asks for the content as text/simple they will get the current atom draft spec. When they ask for it using the mime type application/rdf+owl they will get the document I will present you tomorrow. With this document at hand it will be a lot easier to explain the relation between the spec and the OWL document, either in the current atom spec, or if you really insist, in a separate Draft. That will be machine interpretable xml, ie: running code. Good night, Henry Story On 9 Jan 2005, at 00:25, Paul Hoffman / IMC wrote: > At 12:06 AM +0100 1/9/05, Henry Story wrote: >> The "internet draft" I want to propose is an OWL document. I can get >> this out tomorrow. It will essentially say everything the current >> Atom OWL spec says, but in machine readable form. > > An OWL document is not an Internet Draft. If you cannot create an > Internet Draft, please find someone who agrees with your desires to > help you. > >> All that is required then is that the Atom IETF document this working >> group is working on have some language describing its relation to the >> OWL document. > > That should be included in your Internet Draft. > >> This need not be a very big change to the current document. > > That remains to be seen. The best way we can see it is in your > Internet Draft. Clearly, if it is a small change and the WG wants to > use it, it can be folded into the main document before we send it to > the IETF. > >> I believe it could be done in a few sentences taking my first >> proposal as a guide. > > Great! Let's see them. > >> If anyone has some good ideas on where it would be best to change >> the language, please help me along and write that out. > > That is actually the least important point in your proposal, and the > easiest to take care of late in the process if the WG agrees to the > incorporation. If the WG doesn't agree to the incorporation, it isn't > needed at all in your Internet Draft. > >> I can do with all the help out there :-) > > So can we all... > >> Understand that all I am proposing is a machine readable rewriting of >> what the current Atom spec says. > > In order for us to verify that statement, we need to see the > rewriting, and we need to hear from a few people who understand OWL > saying "yup, that exactly matches what is in the format draft". > >> That is most of what there is to it. The rest is just asking for a >> little good will. > > Fully disagree. The rest is the WG coming to consensus on whether or > not we want this as part of the baseline spec. Given this WG's > propensity to disagree about most things XML and RDF, assuming that > will come easily is not based on even a casual reading of the mailing > list. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-atom-syntax@mail.imc.org Sat Jan 8 19:00: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 TAA08359 for ; Sat, 8 Jan 2005 19:00: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 j08No0Oq094298; Sat, 8 Jan 2005 15:50: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 j08No0xP094297; Sat, 8 Jan 2005 15:50:00 -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 j08NntvF094000 for ; Sat, 8 Jan 2005 15:49:55 -0800 (PST) (envelope-from bob@wyman.us) Received: from localhost (localhost [127.0.0.1]) by mailrelay.t-mobile.com (Postfix) with ESMTP id 528DE99DC for ; Sat, 8 Jan 2005 17:45: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 16571-06 for ; Sat, 8 Jan 2005 17:45:47 -0600 (CST) Received: from boblaptop (unknown [10.255.205.37]) by mailrelay.t-mobile.com (Postfix) with ESMTP for ; Sat, 8 Jan 2005 17:45:47 -0600 (CST) Reply-To: From: "Bob Wyman" To: "'Atom Syntax'" Subject: Please Review: Dissemination of Earthquake / Tsunami data via Atom Date: Sat, 8 Jan 2005 18:49:48 -0500 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C4F5B2.D4722250" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcT13GROkNSRvIJ/S228s/ELbbcWDA== Message-Id: <20050108234548.528DE99DC@mailrelay.t-mobile.com> 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_0027_01C4F5B2.D4722250 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit At PubSub, we're beginning to put together a live feed of earthquake and tsunami information in the hope that by making this information more widely and rapidly disseminated, we'll be able to prevent at least a tiny amount of the troubles such as recently happened in the Indian Ocean. In collecting this data, we're not simply polling the USGS RSS feeds - doing that would introduce too much latency in the process and such high latency or delays would be unacceptable for this kind of data. What we're doing is connecting to live "push" feeds of data and then executing on our servers the complex and messy "clean-up", validation and reformatting processes that are required. The instant we have good data, we push it out to our subscribers using "Atom over XMPP/PubSub" and, as always, insert the latest messages into our subscriber's personal Atom and/or RSS files. This service will be made available for at least experimental use in a few days after we've completed some testing. We currently expect to provide both traditional PubSub subscription service as well as a "telnet feed" of raw data that other service providers will be able to use to build their own systems. We think it is appropriate to feed this kind of data over PubSub and in Atom files but before we get too far down this road, I'd like to get some input from the Atom community about the format we're thinking about using. A sample Atom 0.3 entry from the current system is provided below. Please take a look at it, provide whatever comments you consider appropriate and also consider my questions below: 1. The first thing to note is that the content is xml, not text or XHTML. The thinking here is that we really want to be able to provide "data" to end users since it is likely that the best way to use this data is to have some kind of application (like a mapper, etc.) that would process the data. It is, I think, less interesting to provide text. However, some folk will want a machine generated textual version of this message. Since Atom only allows us one content element, there is no way to do both data and text - or, am I missing something? (Note: I do not want to convert this XML to XHTML.) 2. I've been thinking that I might include an atom:summary element that contained a textual version of the XML data carried in the content field. However, it appears that most aggregators today display either the summary or the content but don't display both... 3. I've provided a 'rel="alternate"' link that points to a USGS generated HTML page describing the event. Is it legitimate to point to an "alternate" that I haven't created myself? 4. The title field provides some reasonably compact user data summarizing the key data for the event. Would that be sufficient as a "textual representation"? 5. What should a client do when presented with this data? Clearly, there are all sorts of interesting things that one can do if you know the format and build a custom app. However, it would be nice to allow "dumb" clients to do something useful without having to force the format to lowest-common-denominator (i.e. HTML or XHTML). I think what I'd like to do is provide a pointer to an XSL-template in some standard manner. Then, a client could fetch the style sheet and generate something for display. Is this reasonable? If so, where would I identify the style sheet? 6. This kind of data is really sensitive. I would very much like to be able to use a Digital signature to ensure that we can repudiate any fake messages that might get generated by spammers and other idiots as well as to repudiate mangled versions of the data that might get produced down-stream of us. The subject of signing Atom entries doesn't seem to be getting much attention. Can we wake this one up again? I really do not think that signing should be considered something "outside the core" and subject to individual or proprietary extensions. I look forward to your comments and assistance in getting this system working - hopefully, long before the next disaster in which it might be useful. bob wyman Note: The message below was published long after the original event. The reason for the delay is that this message adds to information previously published - much closer to the time of the event. (i.e. the "AddOn" element with the links to the waveforms was not available when the event was first published.) If a tsunami warning was issued, it would also appear as an "AddOn". 2005-01-08T16:49:18-05:00 2005-01-08T16:49:18-05:00 tag:pubsub.com,2005:EQ:ci14117540 M 1.8 SOUTHERN CALIFORNIA 2005-01-08T21:00:21.000Z http://earthquake.usgs.gov/recenteqs/Quakes/ci14117540.htm Earthquakes PubSub Earthquake Publisher 14117540 2 2005-01-08T16:49:18-0500 EQMessage ------=_NextPart_000_0027_01C4F5B2.D4722250 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

At PubSub, we’re beginning to put together a live feed of earthquake and tsunami information in the hope that by making this = information more widely and rapidly disseminated, we’ll be able to prevent at = least a tiny amount of the troubles such as recently happened in the Indian = Ocean. In collecting this data, we’re not simply polling the USGS RSS feeds = – doing that would introduce too much latency in the process and such high latency or delays would be unacceptable for this kind of data. What = we’re doing is connecting to live “push” feeds of data and then = executing on our servers the complex and messy “clean-up”, validation = and reformatting processes that are required. The instant we have good data, = we push it out to our subscribers using “Atom over XMPP/PubSub” and, = as always, insert the latest messages into our subscriber’s personal = Atom and/or RSS files. This service will be made available for at least = experimental use in a few days after we’ve completed some testing. We currently = expect to provide both traditional PubSub subscription service as well as a = “telnet feed” of raw data that other service providers will be able to use = to build their own systems.

 

We think it is appropriate to feed this kind of data over PubSub = and in Atom files but before we get too far down this road, I’d like to = get some input from the Atom community about the format we’re thinking = about using. A sample Atom 0.3 entry from the current system is provided below. = Please take a look at it, provide whatever comments you consider appropriate and = also consider my questions below:

 

1.    = The first thing to note is that the content is xml, not text or XHTML. The = thinking here is that we really want to be able to provide “data” to = end users since it is likely that the best way to use this data is to have = some kind of application (like a mapper, etc.) that would process the data. = It is, I think, less interesting to provide text. However, some folk will want a = machine generated textual version of this message… Since Atom only allows = us one content element, there is no way to do both data and text – or, am = I missing something? (Note: I do not want to convert this XML to = XHTML…)

2.    = I’ve been thinking that I might include an atom:summary element that = contained a textual version of the XML data carried in the content field. However, = it appears that most aggregators today display either the summary or the = content but don’t display both...

3.    = I’ve provided a ‘rel=3D”alternate”’ link that points = to a USGS generated HTML page describing the event. Is it legitimate to point to = an “alternate” that I haven’t created myself?

4.    = The title field provides some reasonably compact user data summarizing the = key data for the event. Would that be sufficient as a “textual = representation”?

5.    = What should a client do when presented with this data? Clearly, there are all = sorts of interesting things that one can do if you know the format and build a = custom app. However, it would be nice to allow “dumb” clients to do something useful without having to force the format to lowest-common-denominator (i.e. HTML or XHTML). I think what I’d = like to do is provide a pointer to an XSL-template in some standard manner. = Then, a client could fetch the style sheet and generate something for display. = Is this reasonable? If so, where would I identify the style = sheet?

6.    = This kind of data is really sensitive… I would very much like to be = able to use a Digital signature to ensure that we can repudiate any fake messages = that might get generated by spammers and other idiots as well as to repudiate = mangled versions of the data that might get produced down-stream of us. The = subject of signing Atom entries doesn’t seem to be getting much attention. = Can we wake this one up again? I really do not think that signing should be = considered something “outside the core” and subject to individual or proprietary extensions.

 

I look forward to your comments and = assistance in getting this system working – hopefully, long before the next disaster in = which it might be useful.

 

bob wyman

 

Note: The message below was published long after the original = event. The reason for the delay is that this message adds to information = previously published – much closer to the time of the event. (i.e. the = “AddOn” element with the links to the waveforms was not available when the event = was first published.) If a tsunami warning was issued, it would also appear = as an “AddOn”.

 

<entry>

<modified>2005-01-08T16:49:18-05:00</modified>

<issued>2005-01-08T16:49:18-05:00</issued>=

<id><id>tag:pubsub.com,2005:EQ:ci14117540</id>&= lt;/id>

<title>M 1.8 SOUTHERN CALIFORNIA = 2005-01-08T21:00:21.000Z</title>

<link = rel=3D"alternate">http://earthquake.usgs.gov/recenteqs/Quake= s/ci14117540.htm</link>

<content type=3D'text/xml' = xmlns=3D'http://pubsub.com/xmlns'>

<Message>

<topic>Earthquakes</topic>

<publisher>PubSub Earthquake = Publisher</publisher>

<messageID>14117540</messageID>

<revisionID>2</revisionID>

<publication-date>2005-01-08T16:49:18-0500</publication-= date>

<contentType>EQMessage</contentType>

<content>

<Earthquake MsgNumber=3D"1411754002" MsgVersion=3D"1.0" >

<DataMessage Action=3D"Add" TimeReceived=3D"2005-01-08T16:49:18-0500">=

<Identifier EventIDKey=3D"ci14117540" DataSource=3D"CI" = Version=3D"1"/>

<Event Type=3D"Earthquake" Version=3D"1" MsgTypeCode=3D"E " Latitude=3D"34.6391" Longitude=3D"-118.573" Depth=3D"8.3" = NumPhases=3D"27" MinDistance=3D"5" AzimuthalGap=3D"57.6" = RMSTimeError=3D"0.28" HorizontalError=3D"0.5" VerticalError=3D"1.8" Time=3D"2005-01-08T21:00:21.000Z" = LocationMethod=3D"H" Verified=3D"N">

<Magnitude Value=3D"1.8" Type=3D"L" NumStations=3D"16" = MagError=3D"0.3"/>

</Event>

<AddOn Type=3D"Waveform_CI" Version=3D"1" Link=3D"http://pasadena.wr.usgs.gov/review_eventfiles/14117540.html&= quot; Description=3D"Waveforms"></AddOn>

</DataMessage>

</Earthquake>

</content>

</Message>

</content>

</entry>

 

------=_NextPart_000_0027_01C4F5B2.D4722250-- From owner-atom-syntax@mail.imc.org Sat Jan 8 19:13: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 TAA09025 for ; Sat, 8 Jan 2005 19:13: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 j0904fPH004777; Sat, 8 Jan 2005 16:04: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 j0904fZL004776; Sat, 8 Jan 2005 16:04:41 -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 j0904f9I004702 for ; Sat, 8 Jan 2005 16:04:41 -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 <2005010900044101500n1r04e>; Sun, 9 Jan 2005 00:04:41 +0000 Date: Sat, 8 Jan 2005 17:04:39 -0700 Subject: Re: Atom extensibility 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: <0E8C57EF-61D2-11D9-A087-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, January 7, 2005, at 09:33 PM, Eric Scheid wrote: > On 8/1/05 11:03 AM, "Antone Roundy" wrote: >> (This seems so >> intuitively obvious that I wouldn't think people would make XML that >> didn't work this way, but from the sound of it, there are examples out >> there of XML where child elements aren't related to their parents. I >> for one would understand the importance of making this explicit if I >> could see such examples). > > it's often not so much a case of breaking a parent-child relationship, > but > asserting a sibling relationship ... even in atom, we already have > /feed/head/author which applies to /feed/entry. > > What happens when some moblogger wants to put into > /feed/head > but have it apply to all /feed/entry except where there are specific > for a given ? > Ah, good point--we have indeed built something that isn't a pure tree structure, but we haven't explicitly stated anything general about whether extensions are allowed to work that way or not. So do we want to say something along the lines of "Except as otherwise provided by the Atom specification, elements and attributes affect the meaning only of their (immediate?) parent elements. For example, the values of extension elements appearing as children of the feed and head elements are not inherited by the feed's entries." I'd be in favor or some sort of language clarifying the point that exceptions to the pure tree structure are only allowed where defined by the Atom specification. If we DO want to allow extensions to violate the pure tree structure, we should to define a mechanism for doing so such as one (or more) of the following: 1) Define a method of explicitly stating that an element appearing at the feed level is a default value for entries that don't override it. A method of expressing "no value" for arbitrary extension elements, to override the default, would be necessary. 2) Define a method of assigning an identifier to an element which could be referenced from elsewhere irrespective of the tree structure (RDF provides one such method). 3) Have a "mustUnderstand" mechanism, and require any extension which violates pure-tree structure to be marked "mustUnderstand". I think that over time, I've been an advocate of examples of each of the foregoing. Both #1 and #2 would make processing Atom somewhat more complex, so I could take them or leave them both without complaint. I don't see a downside to #3 (either for this specific purpose, or more generally as a way to avoid misunderstanding of extensions when such misunderstanding has potential for causing problems). From owner-atom-syntax@mail.imc.org Sat Jan 8 19:28: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 TAA09618 for ; Sat, 8 Jan 2005 19:28: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 j090KFDs019501; Sat, 8 Jan 2005 16: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 j090KF5A019500; Sat, 8 Jan 2005 16:20:15 -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 j090KEX0019486 for ; Sat, 8 Jan 2005 16:20:14 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 5118 messnum 2833184 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 9 Jan 2005 00:20:14 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.150?) (83.70.164.213) by mail07.svc.cra.dublin.eircom.net (qp 5118) with SMTP; 9 Jan 2005 00:20:14 -0000 Message-ID: <41E078D1.9060200@dehora.net> Date: Sun, 09 Jan 2005 00:20:33 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'Atom WG'" , Tim Bray Subject: Re: Atom extensibility, RDF, and GRDDL References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <41DF09C8.9090307@intertwingly.net> <41DF1641.7060405@franklinmint.fm> <41E008FB.7060609@dehora.net> <1088C779-61A1-11D9-A2C8-000A95A51C9E@sun.com> <41E0785D.4020001@dehora.net> In-Reply-To: <41E0785D.4020001@dehora.net> 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 Bill de hÓra wrote: > Look, the point is this. Those arguing from the RDF side of the house do > mean what you mean by extensible. Furthermore, what is meant there by Dammit. Sorry, that should be, those arguing from the RDF side of the house do *not* mean what you mean by extensible. cheers Bill From owner-atom-syntax@mail.imc.org Sat Jan 8 19: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 TAA09718 for ; Sat, 8 Jan 2005 19: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 j090IKCB017056; Sat, 8 Jan 2005 16: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 j090IKrl017053; Sat, 8 Jan 2005 16:18:20 -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 j090IJ5L016751 for ; Sat, 8 Jan 2005 16:18:19 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 10219 messnum 2837871 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 9 Jan 2005 00:18:18 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.150?) (83.70.164.213) by mail06.svc.cra.dublin.eircom.net (qp 10219) with SMTP; 9 Jan 2005 00:18:18 -0000 Message-ID: <41E0785D.4020001@dehora.net> Date: Sun, 09 Jan 2005 00:18:37 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'Atom WG'" Subject: Re: Atom extensibility, RDF, and GRDDL References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <41DF09C8.9090307@intertwingly.net> <41DF1641.7060405@franklinmint.fm> <41E008FB.7060609@dehora.net> <1088C779-61A1-11D9-A2C8-000A95A51C9E@sun.com> In-Reply-To: <1088C779-61A1-11D9-A2C8-000A95A51C9E@sun.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 Tim Bray wrote: > On Jan 8, 2005, at 8:23 AM, Bill de hÓra wrote: > >> My answer to this question is that Atom doesn't have a model in terms >> of being able to talk about extension so there's no point discussing >> it. Extensibility is probably out of scope for the format. > > I'm not going to let that go unchallenged. The ability to put your own > markup in a feed entry and be confident that it will not cause receiving > software to break, and that it will be there for receiving software that > actually knows how to deal with it, is what many people describe using > the word "extensibility". I think that Atom is, in a popular usage of > the term (a large majority usage, I'd bet, but without backing > statistics) extensible. The ability to add new structures that have not a lot to do with the existing structures sounds like modularity. Being able to process what is expected to be there in the face of stuff that is not expected to be there sounds a lot like robustness. We could go at this all month. In truth, I have no problem agreeing to your use of the term. > The people who insist that you have to have to buy into a > graph-theoretical KR model to be able to use the word "extensible" live > in a universe that is self-consistent, but it's not the one where I > work. Look, the point is this. Those arguing from the RDF side of the house do mean what you mean by extensible. Furthermore, what is meant there by extensible hasn't been demonstrated (in my mind) as a requirement for Atom. Thus, in some respects we're having a pointless discussion. One side or the other is going to have to give up possession of the term extensible, or we're going to continue to watch people talk past each other. Once you appreciate that we are talking about two different things, execution of the work in hand will become simpler. cheers Bill From owner-atom-syntax@mail.imc.org Sat Jan 8 19:30: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 TAA09757 for ; Sat, 8 Jan 2005 19:30: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 j090Liwg019639; Sat, 8 Jan 2005 16:21: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 j090LieV019638; Sat, 8 Jan 2005 16:21: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.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j090LhQp019621 for ; Sat, 8 Jan 2005 16:21:43 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so672957rnz for ; Sat, 08 Jan 2005 16:21: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=LocEpggLz3TJftXGDib9GIjni1F5u/tRKlePSNDSE0xy1eTGlzxXLMJ1bDY2Rzl+CGGZHNc15Ww68Dt6ee9IC2uRd1L8e+57NfrusP1doMWExTMfMjuP8KHwWJrWzHTbO5UQaW90oaAERtSl6wtYNY6wqxrvVhlPNg2yHGT6vBg= Received: by 10.38.206.12 with SMTP id d12mr795580rng; Sat, 08 Jan 2005 16:21:43 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sat, 8 Jan 2005 16:21:43 -0800 (PST) Message-ID: <1f2ed5cd0501081621177dacc5@mail.gmail.com> Date: Sun, 9 Jan 2005 01:21:43 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Scott Hollenbeck Subject: Re: Comment on process Cc: atom-syntax@imc.org In-Reply-To: <20050108222413.MSVO16431.lakermmtao05.cox.net@A31P> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd0501081403144e7bc6@mail.gmail.com> <20050108222413.MSVO16431.lakermmtao05.cox.net@A31P> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 8 Jan 2005 17:26:14 -0500, Scott Hollenbeck wrote: > > No-one gains anything from overly protracted discussion. But > > I don't seen any extraordinary circumstances that might > > justify the imposition of cloture. Is there something related > > to the (still unexplained) "deadline" mentioned in Tim's recent post? > > I'm not sure that I understand why you believe the "deadline" is > unexplained. Take a look at the charter for this working group: > > http://www.ietf.org/html.charters/atompub-charter.html > > There are goals and milestones identified with due dates. The working group > chairs have an obligation to keep the working group on track to meet those > milestones. They can set interim goals for smaller tasks if they feel it's > necessary. > > Given that the goals and milestones were agreed upon as part of the creation > of this working group, what's not clear? When Tim referred to "Our deadline" in the context of "the result of discussions between Paul and myself, and is our position" [1] it wasn't clear which "our" and hence which deadline he was talking about. This question was asked directly in a subsequent post [2]. So ok, the charter includes the following Goal/Milestone: Mar 05 Request Last Call for Atom feed format I will assume this is the deadline in question. Thanks for the clarification. Cheers, Danny. [1] http://www.imc.org/atom-syntax/mail-archive/msg11896.html [2] http://www.imc.org/atom-syntax/mail-archive/msg11916.html -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Jan 8 19:40: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 TAA10156 for ; Sat, 8 Jan 2005 19:40: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 j090RcHa020301; Sat, 8 Jan 2005 16: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 j090RcPC020300; Sat, 8 Jan 2005 16:27:38 -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 j090RbRn020289 for ; Sat, 8 Jan 2005 16:27:38 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 49664 messnum 5116069 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 9 Jan 2005 00:27:38 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.150?) (83.70.164.213) by mail13.svc.cra.dublin.eircom.net (qp 49664) with SMTP; 9 Jan 2005 00:27:38 -0000 Message-ID: <41E07A8D.1040308@dehora.net> Date: Sun, 09 Jan 2005 00:27:57 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom WG Subject: Re: Hash for Links [Was: Re: Posted PaceEnclosuresAndPix] References: <1f2ed5cd050105162514f7773f@mail.gmail.com> <1f2ed5cd050106050455c75c9d@mail.gmail.com> <2bcdc7c405010609374df235f3@mail.gmail.com> <41E01953.7030404@dehora.net> <41E03C53.1000701@franklinmint.fm> In-Reply-To: <41E03C53.1000701@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: > Well, Content-Length lives in the attributes as "length", but I don't > think we need to make a home for every HTTP header. Content-MD5 will > work just fine; it would probably be wise to send a HEAD request before > automatically downloading a giant mp3. Furthermore, you'll get a good > enough identifier by concatenating the URI and the length. Something > more accurate will require a HEAD request. Thirdly, there's absolutely > no reason to have this in core. I'm fine with all that - a good rationale. But no-one's asking to make a home for every HTTP header here. cheers Bill From owner-atom-syntax@mail.imc.org Sat Jan 8 19:40: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 TAA10177 for ; Sat, 8 Jan 2005 19:40: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 j090VYaj021060; Sat, 8 Jan 2005 16:31: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 j090VYp9021059; Sat, 8 Jan 2005 16:31: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.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j090VXaP021008 for ; Sat, 8 Jan 2005 16:31:33 -0800 (PST) (envelope-from jalkanen@gmail.com) Received: by wproxy.gmail.com with SMTP id 37so48686wra for ; Sat, 08 Jan 2005 16:31:31 -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=CrkHOvRrkikc+bqGe6m/KCDKCokVjclbd5aQRzcYkZtofjkOGHNyDLIqKQyU8K//QUDoUs26X/7JI7kNH+Cix1VprY64shUFM4mU8Wggxguc2tdmWYt3XXo9KM6/ZaoUV9kZLX0F0mUyZDGhWKlwr8SmmkBpVpqTAzXPnmJ9z0c= Received: by 10.54.3.32 with SMTP id 32mr400100wrc; Sat, 08 Jan 2005 16:31:31 -0800 (PST) Received: by 10.54.44.79 with HTTP; Sat, 8 Jan 2005 16:31:31 -0800 (PST) Message-ID: <7aebae7d050108163133a3a2c5@mail.gmail.com> Date: Sun, 9 Jan 2005 02:31:31 +0200 From: Janne Jalkanen Reply-To: Janne Jalkanen To: Graham Subject: Re: Hash for Links [Was: Re: Posted PaceEnclosuresAndPix] Cc: Atom WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd050105162514f7773f@mail.gmail.com> <1f2ed5cd050106050455c75c9d@mail.gmail.com> <2bcdc7c405010609374df235f3@mail.gmail.com> <41E0464A.6090802@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 8 Jan 2005 20:49:55 +0000, Graham wrote: > Well, for that example, it's not so necessary. But I've heard of one > suggested usage being: > > > > Which would require reloading to maintain feature parity with > non-external content. How about putting HTTP etags directly in the feed? Might work for enclosures as well... /Janne From owner-atom-syntax@mail.imc.org Sat Jan 8 20:06: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 UAA11084 for ; Sat, 8 Jan 2005 20:06: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 j090uMci027140; Sat, 8 Jan 2005 16:56: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 j090uM3J027139; Sat, 8 Jan 2005 16:56:22 -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 j090uM8O027128 for ; Sat, 8 Jan 2005 16:56:22 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so673598rnz for ; Sat, 08 Jan 2005 16:56:22 -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=DvtpfSRebAV+cHAoehUYTNY2xYK8gEtE1b0D4DySRnZX6hkQQxQ0Ke1VL18QvXr9uRVOfLiuMEeQidPXQQvRyjoIc0JZuoPgALYTNqvIiuy6qOKx+EHGH0Gq6Qa1aU+bDlGfzEHrtMYqeAYJDnSfg+3C8YM3qU5djHvFl4wAtXU= Received: by 10.38.8.13 with SMTP id 13mr795786rnh; Sat, 08 Jan 2005 16:56:22 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sat, 8 Jan 2005 16:56:22 -0800 (PST) Message-ID: <1f2ed5cd0501081656554742d5@mail.gmail.com> Date: Sun, 9 Jan 2005 01:56:22 +0100 From: Danny Ayers Reply-To: Danny Ayers To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: Atom extensibility, RDF, and GRDDL Cc: Atom WG In-Reply-To: <41E0785D.4020001@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <41DF09C8.9090307@intertwingly.net> <41DF1641.7060405@franklinmint.fm> <41E008FB.7060609@dehora.net> <1088C779-61A1-11D9-A2C8-000A95A51C9E@sun.com> <41E0785D.4020001@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j090uM8O027133 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sun, 09 Jan 2005 00:18:37 +0000, Bill de hÓra wrote: > Look, the point is this. Those arguing from the RDF side of the house do [not] > mean what you mean by extensible. Furthermore, what is meant there by > extensible hasn't been demonstrated (in my mind) as a requirement for > Atom. Thus, in some respects we're having a pointless discussion. One > side or the other is going to have to give up possession of the term > extensible, or we're going to continue to watch people talk past each > other. Once you appreciate that we are talking about two different > things, execution of the work in hand will become simpler. I'd be more than happy to use a different term for the XML-extensibility-like thing which isn't modularity or robustness but closer to the dictionary definition. Extendibility perhaps? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Jan 8 20:26: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 UAA11836 for ; Sat, 8 Jan 2005 20:26: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 j091GRLK031319; Sat, 8 Jan 2005 17:16: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 j091GRdt031318; Sat, 8 Jan 2005 17:16:27 -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 j091GRuC031308 for ; Sat, 8 Jan 2005 17:16: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 (rwcrmhc11) with SMTP id <2005010901162701300t6lf8e>; Sun, 9 Jan 2005 01:16:27 +0000 Date: Sat, 8 Jan 2005 18:16:25 -0700 Subject: Re: RSS extensibility 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: <035A9182-6186-11D9-8C94-000A95D9FA7A@bblfish.net> Message-Id: <150977C3-61DC-11D9-A087-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, January 8, 2005, at 08:00 AM, Henry Story wrote: > Now the problem with the graph above, is that it does not make sense to > assign a geo location to an entry. This will probably not be allowed > by the geo ontology, which will probably specify some location class > to be the the subject of such a relation. One may want to imagine some > weird monster called a Entry-geolocation, but it will have all kinds > of weird properties. So let us be throw that monster out of the > window, even though it makes xml sense: it does not make any other > sense at all. > > This is probably what was meant: > > _f1 ---is a---> > |----head----> _h1 > | |---author-> _p1 ---is a---> > | |----email---> henry.story@bblfish.net > | > |----entry---> _e1 --is a---> > |----id-----> > |---date----> "2005-02-02T13:05:04"^^xsd:dateTime > |--content--> _p1 ---is a ---> > |--foaf:home--> _loc ---is > a---> > | |---geo:x--->"10.1" > | |---geo:y--->"57.3" > |--foaf:mbox--> > > > > _f2 ---is a---> > |--head--> .... > |--entry-> _e2 --is a---> > |----id-----> > |---date----> "2005-03-02T07:05:04"^^xsd:dateTime > |--content--> _event1 ---is a ---> > > |--phy:date-->"2005-02-02T13:05:04"^^xsd:dateTime > |--phy:loc---> _loc2 --is a ---> > > | |--geo:x-------> "10.1" > | |--geo:y-------> "57.3" > |--seismo:magnitude-->"7" > [WARNING: What follows is a long exploration of a few issues including the foundations of structural choices for XML. You may want to skim it or ignore it completely.] Good explanation. I see what you're saying. But I'm not convinced of one thing: that it doesn't make sense to assign a geo location to an entry. Perhaps if my mental model of what an entry is were different, I'd feel differently, but it makes as much sense to me for a publisher to want to attach a location to an entry as it does to attach a title to an entry, for example. So what is an entry? My first thought is that it is content and metadata about the content. But thinking of it that way, I run into a little problem: is the metadata about the content, or about the entry? For example, is the creation date the creation date of the content or of the entry? It could be both in some cases, but it's only always going to be the creation date of the entry. I think we can rule out the idea of an entry being just content and metadata about the content. But there's a third possibility, which coincides with your diagram: an entry is content, metadata about the content, and metadata about the entry itself. So a few questions arise: 1) What metadata can be attached to the content? 2) What metadata can be attached to the entry? 3) Is there a practical way to always have metadata appear as an attribute on or child of the thing it describes? To the content: if, as in your _e2, the content is an event, the location where the event occurred makes sense as metadata. I don't think I need to explore this any further. To the entry: the creation date of the entry makes sense as metadata in a very concrete way. I think it's easy to imagine wanting to attach an ID to the entry, but that's a very different thing than the creation date--it is not an inherent property of an entry, but something we attach to it by choice for convenience in referring to or identifying the entry. Similarly, we can assign a title to the entry, which could even conceivably be different from the title of the content, for example, "An essay about dogs" vs. "An entry that carries as its core content an essay about dogs." The title of the content is more obviously useful metadata, but the title of the entry certainly isn't ruled out. Getting back to geo location--it's easy to imagine what the geo location of content would be (the place where something occurred, the place that something is about, the place where the content was written, etc.) I'll admit, I can't imagine what "the location of an entry" would mean. So, on to question #3. Looking at your example, you have the content of one entry being a person, and the other being an event. Obviously, a physical person doesn't travel around the world through the wires wherever the entry is transmitted, and the event doesn't occur inside the XML. So I suppose it would be more accurate to state that the content is information about a person or about an event--ie. it's all metadata. In that case, I'm not quite sure how to even think about the question of the metadata appearing as a child of the content which it describes, because the content is only referred to, it's not actually there. When the content is actually there, as in the case of inline textual content, making the metadata a child of the content that it describes wouldn't really work. For example, if the content is the sentence "This is a pen.", you wouldn't want your XML to look like this...or at least I wouldn't--it would be too difficult to separate the content from its metadata: This is a pen. The first English sentence taught to Japanese students. So we end up violating the pure tree structure ideal in one way or another: A) (metadata describing its sibling): This is a pen The first English sentence taught to Japanese students. B) or (...metadata describing its sibling? or just encapsulation of the actual content for parsing convenience): This is a pen. The first English sentence taught to Japanese students. C) or (fabricating a method of referring to the content that actually lives elsewhere--possibly in an XML document as in the first example, possibly not, as in the second): The first English sentence taught to Japanese students. This is a pen. The guy typing this email. I think A and C make the most sense, which is probably why those are the ways most of us have settled on. While A probably makes less sense than C from a purely technical point of view, it's intuitively easy to understand, and is the least verbose, so I for one prefer that syntax. However, it leads to a situation where it's not explicitly clear whether metadata describes its sibling or its parent. As long as things are not allowed to get too convoluted--ie., children of can ONLY be metadata about or , not about any of the other children of , then things don't get unmanageable. Anyway, coming full circle to assigning a geo location to an entry...I guess technically, the geo location is probably really the location of the content. But it makes sense to me to have it appear as a child of . And I generally don't feel the need to differentiate between the location of the content and the location of the entry, because, the content being the central data of the entry, I rarely feel the need to think of them as different things--my mental model sort of mushes entries and their content together. Whew. I feel better now. Sorry if you read that and didn't get anything out of it. Antone From owner-atom-syntax@mail.imc.org Sat Jan 8 20:31: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 UAA12065 for ; Sat, 8 Jan 2005 20:31: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 j091LS4d034013; Sat, 8 Jan 2005 17:21: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 j091LSc0034012; Sat, 8 Jan 2005 17:21:28 -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 j091LO90033951 for ; Sat, 8 Jan 2005 17:21:27 -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, 9 Jan 2005 13:21:13 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 09 Jan 2005 12:20:31 +1100 Subject: Re: Hash for Links [Was: Re: Posted PaceEnclosuresAndPix] 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 9/1/05 7:28 AM, "Graham" wrote: > I require this functionality in . There is aboslutely > no way I'm initiating 20 HTTP requests (even HEADs) each time the feed > is reloaded. that's what the /feed/entry/modified date is for. e. From owner-atom-syntax@mail.imc.org Sat Jan 8 20:44: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 UAA12617 for ; Sat, 8 Jan 2005 20:44: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 j091a6LP036280; Sat, 8 Jan 2005 17:36: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 j091a6GQ036278; Sat, 8 Jan 2005 17:36: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 j091a63w036263; Sat, 8 Jan 2005 17:36:06 -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 j091aBVu013046; Sat, 8 Jan 2005 18:36: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 <0IA100N050GA09@edgemail1.Central.Sun.COM>; Sat, 08 Jan 2005 18:36:11 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA1000NH0GA7R@mail.sun.net>; Sat, 08 Jan 2005 18:36:10 -0700 (MST) Date: Sat, 08 Jan 2005 17:36:10 -0800 From: Tim Bray Subject: Re: Comment on process In-reply-to: <1f2ed5cd0501081403144e7bc6@mail.gmail.com> To: Danny Ayers Cc: rubys@intertwingly.net, phoffman@imc.org, 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: <1f2ed5cd0501081403144e7bc6@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 8, 2005, at 2:03 PM, Danny Ayers wrote: > I doubt anyone reading Tim's recent posts on the subject of > extensibility could come to any conclusion other than that he is > vehemently opposed I've decided I just don't know. Henry says we need to do nearly nothing, and a few days back I proposed saying data relevant to entry should be a child of entry, and maybe something like that covers it? So frankly, I have no idea what RDF-based extensibility actually means in terms of what's in the spec and what's in the feeds. That's why we totally, absolutely need draft language for this discussion to become meaningful. -Tim From owner-atom-syntax@mail.imc.org Sat Jan 8 20:45: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 UAA12635 for ; Sat, 8 Jan 2005 20:44: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 j091Z6Il036037; Sat, 8 Jan 2005 17:35: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 j091Z6g7036036; Sat, 8 Jan 2005 17:35: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 j091Z5XG036017 for ; Sat, 8 Jan 2005 17:35: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 (sccrmhc13) with SMTP id <200501090135050160023jb8e>; Sun, 9 Jan 2005 01:35:06 +0000 Date: Sat, 8 Jan 2005 18:34:59 -0700 Subject: Re: Please Review: Dissemination of Earthquake / Tsunami data via Atom 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: <20050108234548.528DE99DC@mailrelay.t-mobile.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 Saturday, January 8, 2005, at 04:49 PM, Bob Wyman wrote: > > One quick comment--would not the above XML place in the namespace "http://pubsub.com/xmlns" rather than the Atom namespace? I'd think you need something like this: From owner-atom-syntax@mail.imc.org Sat Jan 8 20: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 UAA12665 for ; Sat, 8 Jan 2005 20: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 j091cZuV036703; Sat, 8 Jan 2005 17:38: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 j091cZMv036702; Sat, 8 Jan 2005 17:38: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 j091cZ83036687 for ; Sat, 8 Jan 2005 17:38:35 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12ld24r.cable.mindspring.com ([69.86.136.155] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CnS23-00012x-Jy; Sun, 09 Jan 2005 01:38:16 +0000 Message-ID: <41E08B15.1000503@franklinmint.fm> Date: Sat, 08 Jan 2005 20:38:29 -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: "'Atom Syntax'" Subject: Re: Please Review: Dissemination of Earthquake / Tsunami data via Atom References: <20050108234548.528DE99DC@mailrelay.t-mobile.com> In-Reply-To: <20050108234548.528DE99DC@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: >2. I've been thinking that I might include an atom:summary element that >contained a textual version of the XML data carried in the content field. >However, it appears that most aggregators today display either the summary >or the content but don't display both... > > The same is true of and in the various RSS versions. I would include the summary. One might reasonably expect they would show the summary if they don't support the content. >5. What should a client do when presented with this data? Clearly, there >are all sorts of interesting things that one can do if you know the format >and build a custom app. However, it would be nice to allow "dumb" clients to >do something useful without having to force the format to >lowest-common-denominator (i.e. HTML or XHTML). I think what I'd like to do >is provide a pointer to an XSL-template in some standard manner. Then, a >client could fetch the style sheet and generate something for display. Is >this reasonable? If so, where would I identify the style sheet? > > This has been brought up before, people felt it was a security risk equal to object tags and javascript. >6. This kind of data is really sensitive. I would very much like to be >able to use a Digital signature to ensure that we can repudiate any fake >messages that might get generated by spammers and other idiots as well as to >repudiate mangled versions of the data that might get produced down-stream >of us. The subject of signing Atom entries doesn't seem to be getting much >attention. Can we wake this one up again? I really do not think that signing >should be considered something "outside the core" and subject to individual >or proprietary extensions. > > > DSig and XMLEnc are in core. http://atompub.org/2004/10/20/draft-ietf-atompub-format-03.html#rfc.section.7 Also, the pubsub namespace declaration should be on . Robert Sayre From owner-atom-syntax@mail.imc.org Sat Jan 8 21:24: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 VAA14144 for ; Sat, 8 Jan 2005 21:24: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 j092Ema1044627; Sat, 8 Jan 2005 18:14: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 j092Emeu044626; Sat, 8 Jan 2005 18:14:48 -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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j092EliW044601 for ; Sat, 8 Jan 2005 18:14:47 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id r35so595702rna for ; Sat, 08 Jan 2005 18:14:50 -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=gAcCvA260LdcXJSwnv54TZd4OQGKj0rjXBXc0s3FrbLpoV5s9a1gS2mFRa/YoI97DarxGxkP8PiBKqCpjfom9HS5hFUHhmzyKx/W8JruZwUuJkjJriMU3q633IGdltGbf26f27+D3b/fpht4mwmGfIe65mM0vThhXVWecY9pTmo= Received: by 10.38.68.14 with SMTP id q14mr179388rna; Sat, 08 Jan 2005 18:14:50 -0800 (PST) Received: by 10.38.72.20 with HTTP; Sat, 8 Jan 2005 18:14:50 -0800 (PST) Message-ID: <2bcdc7c405010818143d6ab41d@mail.gmail.com> Date: Sat, 8 Jan 2005 18:14:50 -0800 From: James Snell Reply-To: James Snell To: Robert Sayre Subject: Re: Hash for Links [Was: Re: Posted PaceEnclosuresAndPix] Cc: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom WG In-Reply-To: <41E03C53.1000701@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <1f2ed5cd050105162514f7773f@mail.gmail.com> <1f2ed5cd050106050455c75c9d@mail.gmail.com> <2bcdc7c405010609374df235f3@mail.gmail.com> <41E01953.7030404@dehora.net> <41E03C53.1000701@franklinmint.fm> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j092EliW044621 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I really don't want to be going down the road of requiring HTTP header equivalents in the Atom feed, etc. All I want is the ability to specify a hash of whatever it is that is being linked to. It could work in both link and content elements and one could easily use the Content-MD5 header to verify whether or not the resource referenced has been modified since the time it was included in the Entry. The URI and the length of the file do not guarantee that the content has not changed and yes, I had considered this as a possible non-core extension but wanted to float it as a core item first. On Sat, 08 Jan 2005 15:02:27 -0500, Robert Sayre wrote: > > Bill de hÓra wrote: > > > > > > >> >> hash="{generated_hash_value}" > >> hashalg="{uri_identifying_the_hash_algorithm_used" /> > >> > >> The hash and hashalg attributes would be optional but MUST appear > >> together. > >> > >> Thoughts? (If we have more than two people respond favorably to this, > >> I'll write up a Pace for it) > > > > > > > > Seems like a good idea - would it be possible to move them into elements? > > > Well, Content-Length lives in the attributes as "length", but I don't > think we need to make a home for every HTTP header. Content-MD5 will > work just fine; it would probably be wise to send a HEAD request before > automatically downloading a giant mp3. Furthermore, you'll get a good > enough identifier by concatenating the URI and the length. Something > more accurate will require a HEAD request. Thirdly, there's absolutely > no reason to have this in core. > > Robert Sayre > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Sat Jan 8 23:59: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 XAA02491 for ; Sat, 8 Jan 2005 23:59: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 j094fj57010847; Sat, 8 Jan 2005 20:41: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 j094fjxJ010845; Sat, 8 Jan 2005 20:41:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j094fhU6010454 for ; Sat, 8 Jan 2005 20:41:44 -0800 (PST) (envelope-from bobwyman@pubsub.com) Received: from boblaptop (68-174-167-137.nyc.rr.com [68.174.167.137]) by mail.pubsub.com (Postfix) with ESMTP id 21BCB72412E; Sat, 8 Jan 2005 23:41:41 -0500 (EST) Reply-To: From: "Bob Wyman" To: "'Atom Syntax'" Cc: "'Robert Sayre'" Subject: Signatures in feeds of Aggregated Entry Documents Date: Sat, 8 Jan 2005 23:41:39 -0500 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C4F5DB.997B8AF0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcT2BYIA2gWTnIUoSDClxIgf4PVSnA== Message-Id: <20050109044141.21BCB72412E@mail.pubsub.com> 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_0006_01C4F5DB.997B8AF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit As Robert Sayre recently wrote: >DSig and XMLEnc are in core. >http://atompub.org/2004/10/20/draft-ietf-atompub-format-03.html#rfc.section .7 However, the text says: "The document element of an Atom document (i.e., atom:feed in an Atom Feed Document, atom:entry in an Atom Entry Document) MAY have an Enveloped Signature" . "Other elements in an Atom document MUST NOT be signed unless their definitions explicitly specify such a capability." The definition of atom:entry does not "explicitly specify" that signatures can be used on an atom:entry that appears within an Atom Feed Document (i.e. as a child of atom:feed). This would seem to imply that I cannot compose an Atom Feed Document by collecting together Atom Entry Documents and wrapping them in a atom:feed - unless I strip out any signatures that might have been in the Atom Entry Documents prior to inserting them in the Atom Feed Document. This is a significant problem for a system like PubSub.com's that composes feeds by combining entries found in Atom Feed Documents or Atom Entry Documents. It also prevents the use of Atom Feed Documents as a means of "logging" a sequence of Atom Entry Documents that may be delivered over time - perhaps via a mechanism like "Atom over XMPP". Additionally, this constraint would prevent "search engines" from delivering up unmodified Atom Entry Documents as elements of result sets that are presented as Atom Feed Documents. (i.e. the search engine might receive signed atom Entry Documents but would be forced to remove the signatures if it returns results as an Atom Feed.) I can't remember if this has been discussed before. I'm tempted to write a Pace which would specify that any atom:entry can be signed - whether it is found in an Atom Feed Document or an Atom Entry Document. Before doing so, I would appreciate if someone could explain if the constraint in the current specification is intentional. Why would a signature not be permitted on an atom:entry found in an Atom Feed Document? bob wyman ------=_NextPart_000_0006_01C4F5DB.997B8AF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As Robert Sayre recently = wrote:

>DSig and XMLEnc = are in core.

>http://atompub.org/2004/10/20/draft-ietf-atompub-format-03.= html#rfc.section.7

 

However, the text says:

“The document element of an = Atom document (i.e., atom:feed in an Atom Feed Document, atom:entry in an = Atom Entry Document) MAY have an Enveloped Signature” … “Other = elements in an Atom document MUST NOT be signed unless their definitions = explicitly specify such a capability.”

The definition of atom:entry does not “explicitly specify” that signatures can be used on an atom:entry that appears within an Atom Feed = Document (i.e. as a child of atom:feed). This would seem to imply that I cannot = compose an Atom Feed Document by collecting together Atom Entry Documents and = wrapping them in a atom:feed – unless I strip out any signatures that might = have been in the Atom Entry Documents prior to inserting them in the Atom = Feed Document. This is a significant problem for a system like = PubSub.com’s that composes feeds by combining entries found in Atom Feed Documents or = Atom Entry Documents. It also prevents the use of Atom Feed Documents as a = means of “logging” a sequence of Atom Entry Documents that may be delivered over time = – perhaps via a mechanism like “Atom over XMPP”. Additionally, = this constraint would prevent “search engines” from delivering up unmodified Atom Entry Documents as elements of result sets that are = presented as Atom Feed Documents. (i.e. the search engine might receive signed = atom Entry Documents but would be forced to remove the signatures if it returns = results as an Atom Feed.)

I = can’t remember if this has been discussed before. I’m tempted to write a = Pace which would specify that any atom:entry can be signed – whether it = is found in an Atom Feed Document or an Atom Entry Document. Before doing = so, I would appreciate if someone could explain if the constraint in the = current specification is intentional. Why would a signature not be permitted on = an atom:entry found in an Atom Feed Document?

  =           bob wyman

 <= /o:p>

 

------=_NextPart_000_0006_01C4F5DB.997B8AF0-- From owner-atom-syntax@mail.imc.org Sun Jan 9 01:55: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 BAA08904 for ; Sun, 9 Jan 2005 01:55: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 j096gLws053012; Sat, 8 Jan 2005 22:42: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 j096gLZP053011; Sat, 8 Jan 2005 22:42:21 -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 j096gLfv052975 for ; Sat, 8 Jan 2005 22:42:21 -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 j096gQTh024870; Sun, 9 Jan 2005 01:42:26 -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 CHQ51878; Sun, 9 Jan 2005 01:42:24 -0500 (EST) Message-Id: <200501090642.CHQ51878@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Tim Bray'" , "'Atom WG'" Subject: RE: The Atom Format end-game (PICS)?? Date: Sun, 9 Jan 2005 01:42:23 -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: AcTzkIhAgKcWOvKWRK2aZg6RNggZrAChSYrA Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > 2. We are close to RSS2 feature-compatibility, we either adopt > image & enclosure or make a conscious decision not to. There are other bits of RSS2 that should be seriously considered -- even if they aren't widely used. For instance, the RSS2 element which contains a PICS[1] statement. As far as I know, virtually noone uses the tag in RSS2.0. Nonetheless, it would probably be wise to support such a thing in Atom. As blogging goes "mainstream," we should be able to show that mechanisms at least exist to do what PICS is attempting to do... bob wyman [1] http://www.w3.org/PICS/ From owner-atom-syntax@mail.imc.org Sun Jan 9 05:41: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 FAA05184 for ; Sun, 9 Jan 2005 05:41: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 j09AJOiD078712; Sun, 9 Jan 2005 02:19: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 j09AJOSW078711; Sun, 9 Jan 2005 02:19: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 j09AJIDi078355 for ; Sun, 9 Jan 2005 02:19:24 -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, 9 Jan 2005 22:19:02 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 09 Jan 2005 21:18:19 +1100 Subject: Re: Signatures in feeds of Aggregated Entry Documents From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20050109044141.21BCB72412E@mail.pubsub.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 9/1/05 3:41 PM, "Bob Wyman" wrote: > This would seem to imply that I cannot compose an > Atom Feed Document by collecting together Atom Entry Documents and wrapping > them in a atom:feed - unless I strip out any signatures that might have been > in the Atom Entry Documents prior to inserting them in the Atom Feed > Document. if an entry in a feed document are signed, then you will have to strip the signature if you either insert a head-in-entry element, or inline the /feed/head/author parts. and of course you won't be able to insert any extra elements of your own without breaking the signature. sidebar: does the signature technology we use for the atom format allow us to state that certain child elements are not to be included in the signature algorithm. I'm thinking of something along the lines of the following... ... ... e. From owner-atom-syntax@mail.imc.org Sun Jan 9 07:23: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 HAA09932 for ; Sun, 9 Jan 2005 07:23: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 j09CAfJV033972; Sun, 9 Jan 2005 04:10: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 j09CAf9E033971; Sun, 9 Jan 2005 04:10: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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j09CAeM0033926 for ; Sun, 9 Jan 2005 04:10:41 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so683190rnz for ; Sun, 09 Jan 2005 04:10: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=ahoZZY834VOrO2UnAaasgPJdFjktQnrCBbKYc6jTVVEX70DstNiJVJGg4ApKvZ/tKSVSV9NXrFJaDTAtg3uwPAWVTrNTxjFzXCx4uGrnR9PBIMpupjHTGDL9N+6vxVA8Fqo/W/S07n5JnkYOmFsRy1C78PACHrOc3so/ggGJ5EY= Received: by 10.38.206.12 with SMTP id d12mr915946rng; Sun, 09 Jan 2005 04:10:36 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sun, 9 Jan 2005 04:10:36 -0800 (PST) Message-ID: <1f2ed5cd05010904103bd000c0@mail.gmail.com> Date: Sun, 9 Jan 2005 13:10:36 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: Comment on process Cc: rubys@intertwingly.net, phoffman@imc.org, atom-syntax@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd0501081403144e7bc6@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 08 Jan 2005 17:36:10 -0800, Tim Bray wrote: > On Jan 8, 2005, at 2:03 PM, Danny Ayers wrote: > > > I doubt anyone reading Tim's recent posts on the subject of > > extensibility could come to any conclusion other than that he is > > vehemently opposed > > I've decided I just don't know. Henry says we need to do nearly > nothing, and a few days back I proposed saying data relevant to entry > should be a child of entry, and maybe something like that covers it? > So frankly, I have no idea what RDF-based extensibility actually means > in terms of what's in the spec and what's in the feeds. That's why we > totally, absolutely need draft language for this discussion to become > meaningful. -Tim Fair enough, thanks. Right now I don't really know what's best either. Hopefully everything will become clear in the next few days... Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sun Jan 9 07:35: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 HAA10395 for ; Sun, 9 Jan 2005 07:35: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 j09CN8tO039620; Sun, 9 Jan 2005 04:23: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 j09CN8wk039619; Sun, 9 Jan 2005 04:23: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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j09CN7KX039581 for ; Sun, 9 Jan 2005 04:23:08 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so683406rnz for ; Sun, 09 Jan 2005 04:23: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:mime-version:content-type:content-transfer-encoding; b=UVl1iOFLPnkF2Fsf2/d5Nh8h+/jz8yFwvzwbnHw8p4dfd/cirX5ozRfSYTQ3KWazzlHKGSDHI8RECeSLA/OmFXscC4GqNwRiPXjBD19au0cM37VuOiQ+e6zj1JJWzOnHgTCkWRsnEPMKQxLFIR5d5xmJIx0zOmapu/6cRMKv3Ho= Received: by 10.38.8.52 with SMTP id 52mr55052rnh; Sun, 09 Jan 2005 04:23:04 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sun, 9 Jan 2005 04:23:04 -0800 (PST) Message-ID: <1f2ed5cd0501090423219e8c42@mail.gmail.com> Date: Sun, 9 Jan 2005 13:23:04 +0100 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: Regarding Graphs 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 There were a couple of points made in recent discussions that might have been misleading. One was that Atom is a tree. The XML may use that structure, and in it's simplest form the information being represented may be tree-shaped, but that isn't necessary the case. For example: ... http://example.org/entry ... If resources are view as nodes, then http://example.org/feed has two parents. The containment tree is violated. From one or two other recent posts a casual bystander might have concluded that it is necessary to know graph theory to use RDF. This isn't really the case. A similar suggestion has been used in the past [1,2,3] to imply RDF is harder than it actually is. In that sense, it's completely unfounded. All you need to know is that RDF data can be visualized as a node and arc (edge) graph. The arcs have a direction, i.e. it's a directed graph. The same information can be represented either as a circle & arrow kind of diagram, as a list of statements (triples) or in one of the serialization formats like RDF/XML or the more human-friendly Turtle. Viewed as a list of statements, the information in the Atom snippet above could be expressed something like: feed hasHref http://example.org/feed feed hasChild entry entry hasID http://example.org/entry entry hasRelated http://example.org/feed Anyone working on the Web is dealing with graphs all the time. There's the Web itself, with pages as nodes and links as arcs. Gopher might have evolved into the World Wide Tree, but didn't. Trees are a constrained subset of graphs, so they can be assimilated in a hugely interconnected environment like the Web (resistance is futile!). Anyone programming is likely to be using considerably more complex graphs than what's usually found in RDF. The relationships between entities in, say, the Java class libraries can get very twisty. (You can use similar visualization, using something like UML). This isn't to suggest that the containment tree of XML isn't useful, far from it. It's a very good fit for most documents we have to deal with, and a considerable amount of data. Other data can be more table-shaped, which can be done in XML but the syntax starts to look a little strained. But many real-world data structures (like the Web) don't fall neatly into trees or tables, and the more general graph can be useful. XML can be used effectively for serialization formats, pretty much irrespective of the data structure. But the syntax may get ugly if the data model is too far removed from Tree. Generally the graph data structure is our friend, and should be welcomed with open arms (or angle brackets). Cheers, Danny. [1] http://static.userland.com/userLandDiscussArchive/msg007482.html [2] http://www.xent.com/aug00/0371.html [3] http://archive.scripting.com/2004/07/16 -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sun Jan 9 08:53: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 IAA14597 for ; Sun, 9 Jan 2005 08:53: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 j09Dchd3071547; Sun, 9 Jan 2005 05:38: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 j09DchD7071546; Sun, 9 Jan 2005 05:38: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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j09Dcgp7071540 for ; Sun, 9 Jan 2005 05:38:43 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so502rnz for ; Sun, 09 Jan 2005 05:38: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=MbHq0Mx1ExZGwuFtHdHLgD1wlKPiyQQPRrDpI2yvXrPREdqvfKfEG7KAtwy9hlTxMxWWsJDyfx/6r+H55PTQqallkJ0XVYVyTHYOZNvP2e/6D7LrgW1pYFBqwAkfgXJh6UuGcUTGWrYAKN1fAQQptfTJTmC6qXhqAQZ3vQz3c7Y= Received: by 10.38.179.15 with SMTP id b15mr4098rnf; Sun, 09 Jan 2005 05:38:41 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sun, 9 Jan 2005 05:38:41 -0800 (PST) Message-ID: <1f2ed5cd05010905387111e8ea@mail.gmail.com> Date: Sun, 9 Jan 2005 14:38:41 +0100 From: Danny Ayers Reply-To: Danny Ayers To: bob@wyman.us Subject: Re: The Atom Format end-game (PICS)?? Cc: Tim Bray , Atom WG In-Reply-To: <200501090642.CHQ51878@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200501090642.CHQ51878@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 9 Jan 2005 01:42:23 -0500, Bob Wyman wrote: > > Tim Bray wrote: > > 2. We are close to RSS2 feature-compatibility, we either adopt > > image & enclosure or make a conscious decision not to. > There are other bits of RSS2 that should be seriously considered -- > even if they aren't widely used. For instance, the RSS2 element > which contains a PICS[1] statement. As far as I know, virtually noone uses > the tag in RSS2.0. Nonetheless, it would probably be wise to > support such a thing in Atom. As blogging goes "mainstream," we should be > able to show that mechanisms at least exist to do what PICS is attempting to > do... The PICS material itself seems very dusty, but ratings came up on the rss-media@yahoo list and the following links were dropped in: http://www.icra.org/vocabulary/ http://www.icra.org/projects/quatro/ The fact that the issue was raised on a list related to Yahoo's media search services does suggest that something like this will be needed in the not-too-distant future. Cheers, Danny. > [1] http://www.w3.org/PICS/ > > -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sun Jan 9 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 MAA25903 for ; Sun, 9 Jan 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 j09HFJlT018705; Sun, 9 Jan 2005 09:15: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 j09HFJB5018703; Sun, 9 Jan 2005 09:15: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 j09HFJMI018480 for ; Sun, 9 Jan 2005 09:15:19 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 18825 invoked by uid 17064); 9 Jan 2005 17:15:08 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.253.244.215]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 9 Jan 2005 17:15:08 -0000 In-Reply-To: References: <2787D98C-61AC-11D9-8C94-000A95D9FA7A@bblfish.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/mixed; boundary=Apple-Mail-2-282142140 Message-Id: Cc: atom-owl@googlegroups.com, Paul Hoffman / IMC From: Henry Story Subject: Re: Closure on Extensibility & RDF: the Atom Ontology Date: Sun, 9 Jan 2005 18:14:37 +0100 To: "'Atom WG'" X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2-282142140 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Attached is the closest I could get today in writing the Atom ontology.=20= There is an N3 and RDF version of the OWL Ontology. For a nice and=20 easily understood reading of the data you can have a look at these=20 files using Prot=E9g=E9 [1]. Of course they can also be read with a = simple=20 text or xml editor. These files illustrate the relationship between the ontology and Atom.=20= As you can see I describe the meaning of each property simply by=20 referring to the IETF Atom chapters. The Atom IETF document is=20 therefore the final arbiter of the meaning of these terms. This exercise has made me aware of the following problem with the spec:=20= there are two title properties that are not quite the same: the title=20 attribute of the link points to a simple string whereas the title of=20 the Head and Entry are more complex structures. As far as the modeling goes I am having difficulty modeling the=20 following elements in Prot=E9g=E9: - the Atom TEXT element seems to be a union of three different = literal=20 types: + string + xml + encoded html is it possible for a property to have three different literals=20 types? - I am not sure how to model the Generator element The whole thing will just make a lot of sense when looked at in=20 Prot=E9g=E9. It is written in Java and so is available on all platforms. Clearly there is ironing out to be done, as I may have missed out a few=20= properties. This ontology should enable us to get very close to our aim which is to=20= have a well formed Atom file be a file that is an rdf graph that uses=20 the above ontology. If we can get the ontology to be a formalization of the spec, then it=20 will be very simple to explain how to extend Atom. Henry Story [1] http://protege.stanford.edu/ --Apple-Mail-2-282142140 Content-Type: application/octet-stream; x-unix-mode=0644; name="Atom.n3" Content-Disposition: attachment; filename=Atom.n3 Content-Transfer-Encoding: quoted-printable #=20Base:=20http://purl.org/atom/#=0A@prefix=20default:=20=20= =20.=0A@prefix=20rdfs:=20=20=20=20= =20.=0A@prefix=20rdf:=20=20=20=20=20= =20.=0A@prefix=20owl:=20=20=20= =20=20=20.=0A=0Adefault:id=0A=20=20=20=20= =20=20a=20=20=20=20=20=20=20owl:InverseFunctionalProperty=20,=20= owl:ObjectProperty=20;=0A=20=20=20=20=20=20rdfs:comment=20"""see=20= section=204.2.8=20for=20Head=0Aand=20section=205.6=20for=20= Entry"""^^=20;=0A=20=20=20=20=20= =20rdfs:domain=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20[=20a=20=20=20= =20=20=20=20owl:Class=20;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20owl:unionOf=20(default:Head=20default:Entry)=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20]=20.=0A=0Adefault:info=0A=20=20=20=20=20=20a=20=20=20=20= =20=20=20owl:DatatypeProperty=20;=0A=20=20=20=20=20=20rdfs:comment=20= """see=20section=204.2.11=0A=0A[[=20the=20range=20of=20this=20property=20= should=20be=20a=20TEXT=20thing=20which=20sounds=20like=20a=20union=20of=20= 3=20different=20types=20of=20literals=20= ]]"""^^=20;=0A=20=20=20=20=20=20= rdfs:domain=20default:Head=20;=0A=20=20=20=20=20=20rdfs:range=20= =20.=0A=0Adefault:copyright=0A=20= =20=20=20=20=20a=20=20=20=20=20=20=20owl:DatatypeProperty=20;=0A=20=20=20= =20=20=20rdfs:comment=20"see=20section=20= 4.2.10"^^=20;=0A=20=20=20=20=20=20= rdfs:domain=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20[=20a=20=20=20=20= =20=20=20owl:Class=20;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= owl:unionOf=20(default:Head=20default:Entry)=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20]=20;=0A=20=20=20=20=20=20rdfs:range=20= =20.=0A=0Adefault:author=0A=20=20= =20=20=20=20a=20=20=20=20=20=20=20owl:ObjectProperty=20,=20= owl:FunctionalProperty=20;=0A=20=20=20=20=20=20rdfs:comment=20"""see=20= section=20=204.2.5=20for=20Head=0Aand=20section=205.4=20for=20= Entry"""^^=20;=0A=20=20=20=20=20= =20rdfs:domain=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20[=20a=20=20=20= =20=20=20=20owl:Class=20;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20owl:unionOf=20(default:Head=20default:Entry)=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20]=20;=0A=20=20=20=20=20=20rdfs:range=20default:Person=20= .=0A=0Adefault:title=0A=20=20=20=20=20=20a=20=20=20=20=20=20=20= owl:DatatypeProperty=20,=20owl:FunctionalProperty=20;=0A=20=20=20=20=20=20= rdfs:comment=20"see=20section=20= 3.5.5"^^=20;=0A=20=20=20=20=20=20= rdfs:domain=20default:Link=20;=0A=20=20=20=20=20=20rdfs:range=20= =20.=0A=0Adefault:email=0A=20=20= =20=20=20=20a=20=20=20=20=20=20=20owl:DatatypeProperty=20,=20= owl:FunctionalProperty=20;=0A=20=20=20=20=20=20rdfs:comment=20"""see=20= section=203.2.3=0A=0A[[this=20definitively=20would=20be=20better=20= associated=20with=20a=20mailto:..=20uri=20and=20be=20inverse=20= functional.=20IE=20one=20should=20conclude=20that=20if=20two=20atom=20= person=20constructs=20are=20related=20to=20the=20same=20mailto=20uri,=20= thery=20are=20the=20same=20person]]=20=0A[[=20it=20also=20seems=20a=20= pitty=20to=20restrict=20the=20number=20of=20emails=20a=20person=20can=20= have=20to=20one]]"""^^=20;=0A=20= =20=20=20=20=20rdfs:domain=20default:Person=20;=0A=20=20=20=20=20=20= rdfs:range=20=20.=0A=0A= default:content=0A=20=20=20=20=20=20a=20=20=20=20=20=20=20= owl:ObjectProperty=20,=20owl:FunctionalProperty=20;=0A=20=20=20=20=20=20= rdfs:comment=20"see=20section=20= 5.10"^^=20;=0A=20=20=20=20=20=20= rdfs:domain=20default:Entry=20;=0A=20=20=20=20=20=20rdfs:range=20= default:Content=20.=0A=0Adefault:feed=0A=20=20=20=20=20=20a=20=20=20=20=20= =20=20owl:Class=20;=0A=20=20=20=20=20=20rdfs:comment=20"""see=20section=20= 4.=20of=20Atom=20Spec=0A[[note:=20it=20would=20be=20more=20in=20sync=20= with=20convention=20of=20class=20names=20for=20feed=20to=20be=20= capitalised=20to=20= \"Feed\"]]"""^^=20;=0A=20=20=20=20= =20=20rdfs:subClassOf=20owl:Thing=20;=0A=20=20=20=20=20=20= rdfs:subClassOf=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20[=20a=20=20=20= =20=20=20=20owl:Restriction=20;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20owl:cardinality=20"1"^^=20= ;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20owl:onProperty=20= default:head=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20]=20;=0A=20=20=20= =20=20=20rdfs:subClassOf=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20[=20= a=20=20=20=20=20=20=20owl:Restriction=20;=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20owl:cardinality=20= "1"^^=20;=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20owl:onProperty=20default:version=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20]=20.=0A=0Adefault:agent=0A=20=20=20=20=20=20= a=20=20=20=20=20=20=20owl:DatatypeProperty=20;=0A=20=20=20=20=20=20= rdfs:comment=20"""see=20section=204.2.9=0A=0A[[=20this=20represents=20= the=20software=20agent=20string=0AI=20can't=20find=20a=20way=20to=20get=20= this=20to=20work=20out=20quite=20right.=20The=20content=20of=20this=20= element=20is=20meant=20to=20be=20the=20content=20of=20the=20agent=20]]=0A= """^^=20;=0A=20=20=20=20=20=20= rdfs:domain=20default:Generator=20;=0A=20=20=20=20=20=20rdfs:range=20= =20.=0A=0Adefault:introspection=0A= =20=20=20=20=20=20a=20=20=20=20=20=20=20owl:ObjectProperty=20,=20= owl:FunctionalProperty=20;=0A=20=20=20=20=20=20rdfs:comment=20"""see=20= section=204.2.3=0A"""^^=20;=0A=20= =20=20=20=20=20rdfs:domain=20default:Head=20;=0A=20=20=20=20=20=20= rdfs:range=20default:Service=20.=0A=0Adefault:Entry=0A=20=20=20=20=20=20= a=20=20=20=20=20=20=20owl:Class=20;=0A=20=20=20=20=20=20rdfs:comment=20= "see=20section=205=20of=20the=20Atom=20= spec"^^=20;=0A=20=20=20=20=20=20= rdfs:subClassOf=20owl:Thing=20;=0A=20=20=20=20=20=20rdfs:subClassOf=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20[=20a=20=20=20=20=20=20=20= owl:Restriction=20;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= owl:cardinality=20"1"^^=20;=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20owl:onProperty=20= default:author=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20]=20;=0A=20=20= =20=20=20=20rdfs:subClassOf=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [=20a=20=20=20=20=20=20=20owl:Restriction=20;=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20owl:maxCardinality=20= "1"^^=20;=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20owl:onProperty=20default:summary=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20]=20;=0A=20=20=20=20=20=20rdfs:subClassOf=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20[=20a=20=20=20=20=20=20=20= owl:Restriction=20;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= owl:maxCardinality=20"1"^^=20;=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20owl:onProperty=20= default:published=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20]=20;=0A=20= =20=20=20=20=20rdfs:subClassOf=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [=20a=20=20=20=20=20=20=20owl:Restriction=20;=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20owl:cardinality=20= "1"^^=20;=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20owl:onProperty=20default:updated=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20]=20;=0A=20=20=20=20=20=20rdfs:subClassOf=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20[=20a=20=20=20=20=20=20=20= owl:Restriction=20;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= owl:maxCardinality=20"1"^^=20;=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20owl:onProperty=20= default:content=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20]=20.=0A=0A= default:Service=0A=20=20=20=20=20=20a=20=20=20=20=20=20=20owl:Class=20;=0A= =20=20=20=20=20=20rdfs:comment=20"""See=20section=203.4=0A= """^^=20.=0A=0A= default:contributor=0A=20=20=20=20=20=20a=20=20=20=20=20=20=20= owl:ObjectProperty=20;=0A=20=20=20=20=20=20rdfs:comment=20"""see=20= section=204.2.6=20for=20Head=0Aans=20section=205.5=20for=20= Element"""^^=20;=0A=20=20=20=20=20= =20rdfs:domain=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20[=20a=20=20=20= =20=20=20=20owl:Class=20;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20owl:unionOf=20(default:Head=20default:Entry)=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20]=20;=0A=20=20=20=20=20=20rdfs:range=20default:Person=20= .=0A=0Adefault:Person=0A=20=20=20=20=20=20a=20=20=20=20=20=20=20= owl:Class=20;=0A=20=20=20=20=20=20rdfs:comment=20"see=20section=20= 3.2"^^=20.=0A=0Adefault:origin=0A= =20=20=20=20=20=20a=20=20=20=20=20=20=20owl:DatatypeProperty=20;=0A=20=20= =20=20=20=20rdfs:comment=20"see=20section=20= 5.12"^^=20;=0A=20=20=20=20=20=20= rdfs:domain=20default:Entry=20;=0A=20=20=20=20=20=20rdfs:range=20= =20.=0A=0Adefault:Link=0A=20=20=20= =20=20=20a=20=20=20=20=20=20=20owl:Class=20;=0A=20=20=20=20=20=20= rdfs:subClassOf=20owl:Thing=20;=0A=20=20=20=20=20=20rdfs:subClassOf=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20[=20a=20=20=20=20=20=20=20= owl:Restriction=20;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= owl:cardinality=20"1"^^=20;=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20owl:onProperty=20default:href=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20]=20;=0A=20=20=20=20=20=20= rdfs:subClassOf=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20[=20a=20=20=20= =20=20=20=20owl:Restriction=20;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20owl:cardinality=20"1"^^=20= ;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20owl:onProperty=20= default:rel=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20]=20.=0A=0A= default:published=0A=20=20=20=20=20=20a=20=20=20=20=20=20=20= owl:DatatypeProperty=20,=20owl:FunctionalProperty=20;=0A=20=20=20=20=20=20= rdfs:comment=20"see=20section=20= 5.8"^^=20;=0A=20=20=20=20=20=20= rdfs:domain=20default:Entry=20;=0A=20=20=20=20=20=20rdfs:range=20= =20.=0A=0Adefault:updated=0A=20= =20=20=20=20=20a=20=20=20=20=20=20=20owl:FunctionalProperty=20,=20= owl:DatatypeProperty=20;=0A=20=20=20=20=20=20rdfs:comment=20"""see=20= section=204.2.12=20for=20Head=0Aand=20section=205.7=20for=20= Entry"""^^=20;=0A=20=20=20=20=20= =20rdfs:domain=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20[=20a=20=20=20= =20=20=20=20owl:Class=20;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20owl:unionOf=20(default:Head=20default:Entry)=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20]=20;=0A=20=20=20=20=20=20rdfs:range=20= =20.=0A=0Adefault:generator=0A= =20=20=20=20=20=20a=20=20=20=20=20=20=20owl:ObjectProperty=20;=0A=20=20=20= =20=20=20rdfs:comment=20"see=20section=20= 4.2.9"^^=20;=0A=20=20=20=20=20=20= rdfs:range=20default:Generator=20.=0A=0Adefault:post=0A=20=20=20=20=20=20= a=20=20=20=20=20=20=20owl:ObjectProperty=20,=20owl:FunctionalProperty=20= ;=0A=20=20=20=20=20=20rdfs:comment=20"see=20section=20= 4.2.4"^^=20;=0A=20=20=20=20=20=20= rdfs:domain=20default:Head=20;=0A=20=20=20=20=20=20rdfs:range=20= default:Service=20.=0A=0Adefault:edit=0A=20=20=20=20=20=20a=20=20=20=20=20= =20=20owl:ObjectProperty=20,=20owl:FunctionalProperty=20;=0A=20=20=20=20=20= =20rdfs:comment=20"see=20section=20= 5.3"^^=20;=0A=20=20=20=20=20=20= rdfs:domain=20default:Entry=20;=0A=20=20=20=20=20=20rdfs:range=20= default:Service=20.=0A=0Adefault:link=0A=20=20=20=20=20=20a=20=20=20=20=20= =20=20owl:ObjectProperty=20;=0A=20=20=20=20=20=20rdfs:comment=20"see=20= section=204.2.2"^^=20;=0A=20=20=20= =20=20=20rdfs:domain=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20[=20a=20= =20=20=20=20=20=20owl:Class=20;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20owl:unionOf=20(default:Head=20default:Entry)=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20]=20;=0A=20=20=20=20=20=20rdfs:range=20= default:Link=20.=0A=0Adefault:rel=0A=20=20=20=20=20=20a=20=20=20=20=20=20= =20owl:FunctionalProperty=20,=20owl:DatatypeProperty=20;=0A=20=20=20=20=20= =20rdfs:comment=20"see=20= 3.5.1"^^=20;=0A=20=20=20=20=20=20= rdfs:domain=20default:Link=20;=0A=20=20=20=20=20=20rdfs:range=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[=20a=20=20=20=20=20=20=20owl:DataRange=20= ;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20owl:oneOf=20= ("alternate"^^=20= "related"^^)=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20]=20.=0A=0Adefault:uri=0A=20=20=20=20=20=20a=20=20= =20=20=20=20=20owl:DatatypeProperty=20,=20owl:FunctionalProperty=20;=0A=20= =20=20=20=20=20rdfs:comment=20"""see=20section=203.2.2=20for=20Person=0A= and=20section=204.2.9=20for=20Generator=0A=0A[[=20note=20that=20it=20may=20= be=20much=20more=20interesting=20to=20associate=20an=20inverse=20= funtional=20uri=20with=20a=20person.=20This=20means=20that=20the=20= person=20is=20identified=20exactly=20by=20that=20uri.=20One=20can=20then=20= use=20the=20URI=20to=20find=20other=20information=20on=20the=20web=20= corresponding=20to=20that=20uri.=20But=20then=20perhaps=20it=20would=20= be=20better=20if=20uri=20were=20defined=20a=20little=20more=20= presicely]]"""^^=20;=0A=20=20=20= =20=20=20rdfs:domain=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20[=20a=20= =20=20=20=20=20=20owl:Class=20;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20owl:unionOf=20(default:Person=20default:Generator)=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20]=20;=0A=20=20=20=20=20=20rdfs:range=20= =20.=0A=0Adefault:head=0A=20=20=20= =20=20=20a=20=20=20=20=20=20=20owl:ObjectProperty=20,=20= owl:FunctionalProperty=20;=0A=20=20=20=20=20=20rdfs:comment=20"see=20= section=204"^^=20;=0A=20=20=20=20= =20=20rdfs:domain=20default:feed=20;=0A=20=20=20=20=20=20rdfs:range=20= default:Head=20.=0A=0Adefault:Content=0A=20=20=20=20=20=20a=20=20=20=20=20= =20=20owl:Class=20;=0A=20=20=20=20=20=20rdfs:comment=20"""see=20section=20= 5.10=0A"""^^=20.=0A=0A= default:src=0A=20=20=20=20=20=20a=20=20=20=20=20=20=20= owl:InverseFunctionalProperty=20,=20owl:DatatypeProperty=20;=0A=20=20=20=20= =20=20rdfs:comment=20"""see=20section=205.10.2=0A=0A[[should=20this=20be=20= inverse=20functional?=20don't=20know=20yet=20= ]]"""^^=20;=0A=20=20=20=20=20=20= rdfs:domain=20default:Content=20;=0A=20=20=20=20=20=20rdfs:range=20= =20.=0A=0Adefault:version=0A=20=20= =20=20=20=20a=20=20=20=20=20=20=20owl:DatatypeProperty=20;=0A=20=20=20=20= =20=20rdfs:comment=20"""see=20section=204.1for=20feed=0Aand=20section=20= 4.2.9=20for=20Generator"""^^=20= ;=0A=20=20=20=20=20=20rdfs:domain=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[=20a=20=20=20=20=20=20=20owl:Class=20;=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20owl:unionOf=20(default:feed=20default:Generator)=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20]=20;=0A=20=20=20=20=20=20rdfs:range=20= =20.=0A=0Adefault:href=0A=20=20=20= =20=20=20a=20=20=20=20=20=20=20owl:FunctionalProperty=20,=20= owl:DatatypeProperty=20;=0A=20=20=20=20=20=20rdfs:comment=20"""see=20= section=203.5.3=20for=20link=20href=0Aand=20section=203.4.1=20for=20= Service=20href"""^^=20;=0A=20=20= =20=20=20=20rdfs:domain=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20[=20= a=20=20=20=20=20=20=20owl:Class=20;=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20owl:unionOf=20(default:Link=20default:Service)=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20]=20;=0A=20=20=20=20=20=20rdfs:range=20= =20.=0A=0Adefault:name=0A=20=20=20= =20=20=20a=20=20=20=20=20=20=20owl:DatatypeProperty=20,=20= owl:FunctionalProperty=20;=0A=20=20=20=20=20=20rdfs:comment=20"""see=20= section=203.2.1=0A=0A[[it=20is=20not=20clear=20why=20one=20should=20= reduce=20the=20number=20of=20names=20a=20person=20has=20to=20= one]]"""^^=20;=0A=20=20=20=20=20= =20rdfs:domain=20default:Person=20;=0A=20=20=20=20=20=20rdfs:range=20= =20.=0A=0Adefault:tagline=0A=20=20= =20=20=20=20a=20=20=20=20=20=20=20owl:DatatypeProperty=20,=20= owl:FunctionalProperty=20;=0A=20=20=20=20=20=20rdfs:comment=20"see=20= section=204.2.7"^^=20;=0A=20=20=20= =20=20=20rdfs:domain=20default:Head=20;=0A=20=20=20=20=20=20rdfs:range=20= =20.=0A=0Adefault:title2=0A=20=20= =20=20=20=20a=20=20=20=20=20=20=20owl:FunctionalProperty=20,=20= owl:DatatypeProperty=20;=0A=20=20=20=20=20=20rdfs:comment=20"""see=20= section=204.2.1=0A=0A[[=20This=20should=20point=20to=20a=20new=20TEXT=20= literal=20type,=20which=20I=20can't=20create=20easily=20in=20Prot=C3=A9g=C3= =A9,=20but=20which=20might=20be=20possible=20in=20RDF=20]]=0A=0A[[=20= There=20is=20a=20clash=20with=20title=20from=20the=20link=20construct=20= which=20can=20only=20be=20of=20type=20string=20= ]]"""^^=20;=0A=20=20=20=20=20=20= rdfs:domain=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20[=20a=20=20=20=20= =20=20=20owl:Class=20;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= owl:unionOf=20(default:Head=20default:Entry)=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20]=20;=0A=20=20=20=20=20=20rdfs:range=20= =20.=0A=0A= =0A=20=20=20=20=20=20a=20=20=20=20=20=20=20= owl:Ontology=20.=0A=0Adefault:type=0A=20=20=20=20=20=20a=20=20=20=20=20=20= =20owl:DatatypeProperty=20,=20owl:FunctionalProperty=20;=0A=20=20=20=20=20= =20rdfs:comment=20"""see=203.5.2=20for=20Link=0Aand=205.10.1=20for=20= Content.=0A=0A[[I=20am=20not=20absolutely=20sure=20these=20are=20the=20= same=20properties,=20though=20they=20are=20very=20similar=20]]=0A= """^^=20;=0A=20=20=20=20=20=20= rdfs:domain=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20[=20a=20=20=20=20= =20=20=20owl:Class=20;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= owl:unionOf=20(default:Link=20default:Content)=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20]=20;=0A=20=20=20=20=20=20rdfs:range=20= =20.=0A=0Adefault:Head=0A=20=20=20= =20=20=20a=20=20=20=20=20=20=20owl:Class=20;=0A=20=20=20=20=20=20= rdfs:comment=20"see=20section=20= 4.2"^^=20;=0A=20=20=20=20=20=20= rdfs:subClassOf=20owl:Thing=20;=0A=20=20=20=20=20=20rdfs:subClassOf=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20[=20a=20=20=20=20=20=20=20= owl:Restriction=20;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= owl:maxCardinality=20"1"^^=20;=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20owl:onProperty=20= default:tagline=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20]=20;=0A=20=20= =20=20=20=20rdfs:subClassOf=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [=20a=20=20=20=20=20=20=20owl:Restriction=20;=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20owl:maxCardinality=20= "1"^^=20;=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20owl:onProperty=20default:post=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20]=20;=0A=20=20=20=20=20=20rdfs:subClassOf=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20[=20a=20=20=20=20=20=20=20= owl:Restriction=20;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= owl:cardinality=20"1"^^=20;=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20owl:onProperty=20default:id=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20]=20;=0A=20=20=20=20=20=20= rdfs:subClassOf=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20[=20a=20=20=20= =20=20=20=20owl:Restriction=20;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20owl:minCardinality=20= "1"^^=20;=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20owl:onProperty=20default:link=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20]=20;=0A=20=20=20=20=20=20rdfs:subClassOf=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20[=20a=20=20=20=20=20=20=20= owl:Restriction=20;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= owl:cardinality=20"1"^^=20;=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20owl:onProperty=20= default:title2=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20]=20;=0A=20=20= =20=20=20=20rdfs:subClassOf=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [=20a=20=20=20=20=20=20=20owl:Restriction=20;=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20owl:maxCardinality=20= "1"^^=20;=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20owl:onProperty=20default:introspection=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20]=20.=0A=0Adefault:hreflang=0A=20=20=20=20= =20=20a=20=20=20=20=20=20=20owl:DatatypeProperty=20,=20= owl:FunctionalProperty=20;=0A=20=20=20=20=20=20rdfs:comment=20"see=20= section=203.5.4"^^=20;=0A=20=20=20= =20=20=20rdfs:domain=20default:Link=20;=0A=20=20=20=20=20=20rdfs:range=20= =20.=0A=0Adefault:summary=0A=20= =20=20=20=20=20a=20=20=20=20=20=20=20owl:DatatypeProperty=20;=0A=20=20=20= =20=20=20rdfs:comment=20"""see=20section=205.9=20=0A[[This=20is=20a=20= TEXT=20construct,=20need=20to=20find=20the=20literal=20that=20goes=20= with=20this=20]]"""^^=20;=0A=20=20= =20=20=20=20rdfs:domain=20default:Entry=20;=0A=20=20=20=20=20=20= rdfs:range=20=20.=0A=0A= default:Generator=0A=20=20=20=20=20=20a=20=20=20=20=20=20=20owl:Class=20= ;=0A=20=20=20=20=20=20rdfs:comment=20"see=20section=20= 4.2.9"^^=20.=0A= --Apple-Mail-2-282142140 Content-Type: application/octet-stream; x-unix-mode=0644; name="Atom.owl" Content-Disposition: attachment; filename=Atom.owl Content-Transfer-Encoding: quoted-printable =0A=0A=20=20=0A=20=20=0A=20=20=20=20= see=20section=203.2=0A=20=20=0A=20= =20=0A=20=20=20=20see=20section=205.10=0A=0A=20=20=0A=20=20= =0A=20=20=20=20=0A=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=201=0A=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=0A=20=20=20=20= =0A= =20=20=20=20=0A=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=201=0A=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=0A=20=20=0A= =20=20=0A=20=20=20=20see=20section=204.=20of=20Atom=20Spec=0A[[note:=20it=20would=20be=20= more=20in=20sync=20with=20convention=20of=20class=20names=20for=20feed=20= to=20be=20capitalised=20to=20"Feed"]]=0A=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=201=0A=20=20=20=20=20=20=0A=20=20= =20=20=0A=20=20=20=20=0A=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=201=0A=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=0A=20=20=20=20= =0A= =20=20=0A=20=20=0A=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=201=0A=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=201=0A=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=201=0A=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20=20=0A=20= =20=20=20=0A=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=201=0A=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=0A=20=20=20=20= =0A= =20=20=20=20see=20section=204.2=0A=20=20=20=20=0A=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20= =20=20=20=201=0A=20=20=20=20=20=20=0A=20=20= =20=20=0A=20=20=20=20=0A=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=201=0A=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=0A=20=20=20=20=0A=20=20= =0A=20=20=0A=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=201=0A=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=0A=20=20=20=20=0A=20=20=20= =20=0A=20=20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=201=0A=20=20=20=20=20=20=0A=20=20= =20=20=0A=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=201=0A=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=201=0A=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=201=0A=20=20=20=20=20=20=0A=20= =20=20=20=0A=20=20=20=20see=20section=205=20of=20the=20Atom=20spec=0A=20=20= =0A=20=20=0A=20=20=20=20= See=20section=203.4=0A=0A=20=20=0A= =20=20=0A=20=20=20=20see=20section=204.2.9=0A=20=20=0A=20=20= =0A=20=20=20=20=0A=20=20=20=20see=20section=204.2.6=20for=20Head=0Aans=20section=205.5=20for=20= Element=0A=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=0A=20=20=20=20=0A=20=20= =0A=20=20=0A= =20=20=20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20see=20section=204.2.8=20for=20Head=0Aand=20section=205.6=20for=20= Entry=0A=20=20=20=20= =0A=20=20=0A=20=20=0A=20=20=20=20= =0A=20=20=20=20=0A=20= =20=20=20=0A=20=20=20=20= see=20section=204=0A=20=20= =0A=20=20=0A= =20=20=20=20=0A=20=20=20=20= see=20section=204.2.9=0A=20=20= =0A=20=20= =0A=20=20=20=20see=20section=20=204.2.5=20for=20Head=0Aand=20section=205.4=20for=20= Entry=0A=20=20=20=20=0A=20=20=20=20=0A=20= =20=20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20= =0A=20=20=0A=20=20=0A=20=20=20=20=0A=20=20=20=20=0A=20=20=20=20=0A=20= =20=20=20see=20section=204.2.4=0A=20=20=0A=20= =20=0A=20=20=20=20see=20section=205.3=0A=20=20=20=20=0A=20=20=20=20=0A=20= =20=20=20=0A=20=20= =0A=20=20=0A= =20=20=20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20see=20section=204.2.2=0A=20=20=20=20=0A=20=20=0A=20=20= =0A=20=20=20=20= see=20section=205.10=0A=20=20=20=20= =0A=20=20=20=20=0A=20= =20=20=20=0A=20=20= =0A=20=20= =0A=20=20=20=20=0A=20=20=20=20= =0A=20= =20=20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20see=20section=203.5.3=20for=20link=20href=0Aand=20section=203.4.1=20for=20= Service=20href=0A=20=20=0A=20=20= =0A=20=20=20=20=0A=20=20=20=20= see=20section=204.2.11=0A=0A[[=20the=20range=20of=20this=20= property=20should=20be=20a=20TEXT=20thing=20which=20sounds=20like=20a=20= union=20of=203=20different=20types=20of=20literals=20]]=0A= =20=20=20=20=0A=20=20= =0A=20=20=0A= =20=20=20=20see=20section=204.2.9=0A=0A[[=20this=20represents=20the=20software=20= agent=20string=0AI=20can't=20find=20a=20way=20to=20get=20this=20to=20= work=20out=20quite=20right.=20The=20content=20of=20this=20element=20is=20= meant=20to=20be=20the=20content=20of=20the=20agent=20]]=0A= =0A=20=20=20=20=0A=20=20=20=20= =0A=20=20= =0A=20=20=0A=20=20=20=20see=20section=204.2.10=0A=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20= =0A=20=20=0A=20=20= =0A=20=20=20=20=0A=20=20=20=20=0A=20=20=20=20= see=20section=205.12=0A=20=20= =0A=20=20=0A=20=20=20=20=0A= =20=20=20=20see=203.5.1=0A=20=20=20=20=0A=20= =20=20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20=20= =20=20=20=20=20=20=20=20=20=20related=0A=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20alternate=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20= =0A=20=20=0A=20=20= =0A=20=20=20=20see=20section=205.10.2=0A=0A[[should=20this=20be=20inverse=20= functional?=20don't=20know=20yet=20]]=0A=20=20=20=20= =0A= =20=20=20=20=0A=20=20=20=20= = =0A=20=20=0A=20=20=0A=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=0A=20=20=20=20=0A=20=20=20=20= =0A=20= =20=20=20see=20section=204.2.1=0A=0A[[=20This=20should=20point=20to=20a=20new=20= TEXT=20literal=20type,=20which=20I=20can't=20create=20easily=20in=20= Prot=C3=A9g=C3=A9,=20but=20which=20might=20be=20possible=20in=20RDF=20]]=0A= =0A[[=20There=20is=20a=20clash=20with=20title=20from=20the=20link=20= construct=20which=20can=20only=20be=20of=20type=20string=20= ]]=0A=20=20=20=20=0A=20=20= =0A=20=20=0A=20=20=20=20see=20section=204.2.12=20for=20Head=0Aand=20section=205.7=20for=20= Entry=0A=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=0A=20=20=20=20=0A=20=20=20=20= =0A=20= =20=20=20=0A=20=20= =0A=20=20=0A=20=20=20=20see=20section=205.9=20=0A[[This=20is=20a=20TEXT=20construct,=20need=20= to=20find=20the=20literal=20that=20goes=20with=20this=20= ]]=0A=20=20=20=20=0A=20=20=20=20= =0A=20=20=0A= =20=20=0A=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20see=20section=204.1for=20feed=0Aand=20section=204.2.9=20for=20= Generator=0A=20=20=20=20=0A=20=20= =0A=20=20= =0A=20=20=20=20=0A=20=20=20=20= see=20section=203.2.1=0A=0A[[it=20is=20not=20clear=20why=20= one=20should=20reduce=20the=20number=20of=20names=20a=20person=20has=20= to=20one]]=0A=20=20=20=20=0A=20=20=20=20= =0A=20=20= =0A=20=20=0A=20=20=20=20see=20section=203.5.5=0A=20=20=20=20=0A=20=20=20=20=0A=20=20=20=20= =0A=20=20= =0A=20=20=0A=20=20=20=20=0A=20=20=20=20= =0A=20=20= =20=20=0A=20=20=20=20= see=20section=204.2.7=0A=20=20= =0A=20=20=0A=20=20=20=20see=20section=203.2.3=0A=0A[[this=20definitively=20would=20be=20better=20= associated=20with=20a=20mailto:..=20uri=20and=20be=20inverse=20= functional.=20IE=20one=20should=20conclude=20that=20if=20two=20atom=20= person=20constructs=20are=20related=20to=20the=20same=20mailto=20uri,=20= thery=20are=20the=20same=20person]]=20=0A[[=20it=20also=20seems=20a=20= pitty=20to=20restrict=20the=20number=20of=20emails=20a=20person=20can=20= have=20to=20one]]=0A=20=20=20=20=0A=20=20=20=20=0A=20=20= =20=20=0A=20=20= =0A=20=20=0A=20=20=20=20=0A=20=20=20=20= see=203.5.2=20for=20Link=0Aand=205.10.1=20for=20Content.=0A=0A= [[I=20am=20not=20absolutely=20sure=20these=20are=20the=20same=20= properties,=20though=20they=20are=20very=20similar=20]]=0A= =0A=20=20=20=20=0A=20=20= =20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20= =0A=20=20=0A=20=20= =0A=20=20=20=20= =0A=20=20=20=20=0A=20=20=20= =20see=20section=204.2.3=0A=0A=20=20=20=20=0A=20=20=0A=20=20= =0A=20=20=20=20= = =0A=20=20=20=20see=20section=205.8=0A=20=20=20=20=0A=20=20=20=20=0A=20=20= =0A=20=20=0A=20=20=20=20= =0A=20=20=20=20=0A=20=20=20=20= =0A=20=20= =20=20see=20section=203.5.4=0A=20=20=0A= =20=20=0A=20=20=20=20= =0A= =20=20=20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20see=20section=203.2.2=20for=20Person=0Aand=20section=204.2.9=20for=20= Generator=0A=0A[[=20note=20that=20it=20may=20be=20much=20more=20= interesting=20to=20associate=20an=20inverse=20funtional=20uri=20with=20a=20= person.=20This=20means=20that=20the=20person=20is=20identified=20exactly=20= by=20that=20uri.=20One=20can=20then=20use=20the=20URI=20to=20find=20= other=20information=20on=20the=20web=20corresponding=20to=20that=20uri.=20= But=20then=20perhaps=20it=20would=20be=20better=20if=20uri=20were=20= defined=20a=20little=20more=20presicely]]=0A=20=20=20=20= =0A=20=20= =0A=0A=0A=0A= --Apple-Mail-2-282142140 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-2-282142140-- From owner-atom-syntax@mail.imc.org Sun Jan 9 12: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 MAA26603 for ; Sun, 9 Jan 2005 12: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 j09HgYff043607; Sun, 9 Jan 2005 09:42: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 j09HgY9k043604; Sun, 9 Jan 2005 09:42:34 -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 j09HgXXT043563 for ; Sun, 9 Jan 2005 09:42:33 -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 j09HgXqp013266 for ; Sun, 9 Jan 2005 12:42: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 CHS27604; Sun, 9 Jan 2005 12:42:31 -0500 (EST) Message-Id: <200501091742.CHS27604@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Atom Syntax'" Subject: RE: Please Review: Dissemination of Earthquake / Tsunami data via Atom Date: Sun, 9 Jan 2005 12:42:29 -0500 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01C4F648.AE5B1720" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050108234548.528DE99DC@mailrelay.t-mobile.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcT13GROkNSRvIJ/S228s/ELbbcWDAAjU3lw 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_004B_01C4F648.AE5B1720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I've received a number of off-list comments pointing to CAP (Common Alerting Protocol) defined by the OASIS Emergency Management WG. (see: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency) It is suggested that CAP would be a more appropriate format for disseminating Earthquake reports. I am very familiar with CAP but am quite sure that it isn't appropriate as a format for us to use in this case. I'd like to point out that it is not our intention at PubSub to defining an "Alerting" protocol - in the sense that CAP is an "alerting" protocol. What we are doing with earthquake data, and what we've been doing for some time with Airport Closing/Delay information, is distributing raw data. The issuance of an "alert" of the type that CAP defines requires a subjective and authoritative decision typically made by a governmental or other authoritative organization - or by some machine process sponsored by such an organization. It is one thing to report that an earthquake has occurred. It is quite another to alert people that some action in response to the event is appropriate. We do the former, not the later. I paid the OASIS fees and joined the CAP WG last year, commented extensively on the specification before it was adopted and we've had CAP support built into PubSub since last spring. However, the fact that we couldn't find a good feed of CAP messages combined with our obvious reluctance to generate them ourselves has prevented us from making the topic public. If we could get a stream of CAP messages, we would publish them. However, publishing CAP messages would not replace our publishing of raw Airport, Earthquake, Tsunami or other reports that we might publish in the future such as weather reports, "terror level" reports, flood warnings, automobile traffic reports, etc. All of these messages may be appropriate for inclusion in a stream of CAP Alerts - however, a raw feed such as we're publishing would contain many more messages then one would expect to see issued by a CAP system. Also, by providing specialized formats and service for each of these types, we are able to support them in ways that a generalized system cannot. The CAP protocol is, of course, very general and is not really designed for carrying the sort of detail that is appropriate for a domain specific message such as one focused on earthquakes. Typically, one would expect that a domain specific message would contain much data which is of concern to those who have a specific interest in the domain (academics, hobbyists, etc.) but much of that detail would be irrelevant to the local emergency managers, governmental agencies, and even members of the general public who might be the recipients of CAP messages. It should also be noted that CAP has not, to date, managed to get much input from non-US domain experts or agencies. Thus, it really can't be considered an "international" standard at this point - however, the market for PubSub data is decidedly international. For those who are interested in learning more about CAP, I highly recommend that you check out the OASIS group pointed to above. Also, I've included a sample CAP message (from the draft CAP 1.1 specification) below to show you the CAP approach to alerting. I think even a quick review of the CAP message will show why it might not be appropriate for our immediate purposes. For instance, I would be very concerned about PubSub.com making statements concerning things like "scope", "urgency", "severity", etc. Also, we provide structure (AddOns) in our messages that can't be easily mapped to the name/value "parameter" mechanism which is all that CAP provides for communicating event-type-specific data. It may be that in the future, we may be convinced that it would be appropriate to publish some subset of our event notifications as CAP messages. However, I'm quite sure that even if we did so, we would still find it appropriate to publish the full detail as domain specific messages. If we get demand to publish CAP messages, or a high-quality source of such messages published by others, we will certainly consider publishing the stuff. bob wyman TRI13970876.1 trinet@caltech.edu 2003-06-11T20:56:00-07:00 Actual Alert Public 13970876 Geo Earthquake Past Minor Observed Southern California Seismic Network (TriNet) operated by Caltech and USGS EQ 3.4 Imperial County CA - PRELIMINARY REPORT A minor earthquake measuring 3.4 on the Richter scale occurred near Brawley, California at 8:53 PM Pacific Daylight Time on Wednesday, June 11, 2003. (This is a computer-generated solution and has not yet been reviewed by a human.) http://www.trinet.org/scsn/scsn.html EventID=13970876 Version=1 Magnitude=3.4 Ml Depth=11.8 mi. Quality=Excellent 1 mi. WSW of Brawley, CA; 11 mi. N of El Centro, CA; 30 mi. E of OCOTILLO (quarry); 1 mi. N of the Imperial Fault 32.9525,-115.5527 0 ------=_NextPart_000_004B_01C4F648.AE5B1720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve received a number of = off-list comments pointing to CAP (Common Alerting Protocol) defined by the OASIS Emergency Management WG. (see: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=3Demerg= ency) It is suggested that CAP would be a more appropriate format for = disseminating Earthquake reports. I am very familiar with CAP but am quite sure that = it isn’t appropriate as a format for us to use in this = case.

 

I’d like to point out that it = is not our intention at PubSub to defining an “Alerting” protocol = – in the sense that CAP is an “alerting” protocol. What we are = doing with earthquake data, and what we’ve been doing for some time with Airport Closing/Delay information, is distributing raw data. The = issuance of an “alert” of the type that CAP defines requires a subjective = and authoritative decision typically made by a governmental or other authoritative = organization – or by some machine process sponsored by such an organization. It is one = thing to report that an earthquake has occurred. It is quite another to alert = people that some action in response to the event is appropriate. We do the = former, not the later.

 

I paid the OASIS fees and joined = the CAP WG last year, commented extensively on the specification before it was = adopted and we’ve had CAP support built into PubSub since last spring. = However, the fact that we couldn’t find a good feed of CAP messages = combined with our obvious reluctance to generate them ourselves has prevented us from = making the topic public. If we could get a stream of CAP messages, we would publish = them. However, publishing CAP messages would not replace our publishing of raw Airport, Earthquake, Tsunami or other reports that we might publish in = the future such as weather reports, “terror level” reports, = flood warnings, automobile traffic reports, etc. All of these messages may be appropriate for inclusion in a stream of CAP Alerts – however, a = raw feed such as we’re publishing would contain many more messages then one = would expect to see issued by a CAP system. Also, by providing specialized formats = and service for each of these types, we are able to support them in ways that a = generalized system cannot.

 

The CAP protocol is, of course, = very general and is not really designed for carrying the sort of detail that = is appropriate for a domain specific message such as one focused on = earthquakes. Typically, one would expect that a domain specific message would contain = much data which is of concern to those who have a specific interest in the = domain (academics, hobbyists, etc.) but much of that detail would be irrelevant = to the local emergency managers, governmental agencies, and even members of the general public who might be the recipients of CAP messages. It should = also be noted that CAP has not, to date, managed to get much input from non-US = domain experts or agencies. Thus, it really can’t be considered an = “international” standard at this point – however, the market for PubSub data is = decidedly international.

 

For those who are interested in = learning more about CAP, I highly recommend that you check out the OASIS group = pointed to above. Also, I’ve included a sample CAP message (from the draft = CAP 1.1 specification) below to show you the CAP approach to alerting. I = think even a quick review of the CAP message will show why it might not be = appropriate for our immediate purposes. For instance, I would be very concerned about PubSub.com making statements concerning things like “scope”, = “urgency”, “severity”, etc. Also, we provide structure (AddOns) in our messages that can’t be easily mapped to the name/value = “parameter” mechanism which is all that CAP provides for communicating = event-type-specific data.

 

It may be that in the future, we = may be convinced that it would be appropriate to publish some subset of our = event notifications as CAP messages. However, I’m quite sure that even if we did so, = we would still find it appropriate to publish the full detail as domain specific messages. If we get demand to publish CAP messages, or a high-quality = source of such messages published by others, we will certainly consider publishing = the stuff.

 

      =       bob wyman

 

 

<?xml version =3D "1.0" encoding =3D = "UTF-8"?>

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

   = <identifier>TRI13970876.1</identifier> 

   = <sender>trinet@caltech.edu</sender> 

   = <sent>2003-06-11T20:56:00-07:00</sent>

   = <status>Actual</status> 

   = <msgType>Alert</msgType>

   = <scope>Public</scope>

   = <incidents>13970876</incidents>

   = <info>

        = ;  <category>Geo</category>   

        = ;  <event>Earthquake</event>   

        = ;  <urgency>Past</urgency>   

        = ;  <severity>Minor</severity>   

        = ;  <certainty>Observed</certainty>

        = ;  <senderName>Southern California Seismic Network (TriNet) operated by Caltech and = USGS</senderName>

        = ;  <headline>EQ 3.4 Imperial County CA - PRELIMINARY = REPORT</headline>

        = ;  <description>A minor earthquake measuring 3.4 on the Richter scale occurred near = Brawley, California at 8:53 PM Pacific Daylight Time on Wednesday, June 11, 2003. (This is a = computer-generated solution and has not yet been reviewed by a = human.)</description>

        = ;  = <web>http://www.trinet.org/scsn/scsn.html</web>

        = ;  = <parameter>EventID=3D13970876</parameter>

        = ;  = <parameter>Version=3D1</parameter>

        = ;  <parameter>Magnitude=3D3.4 Ml</parameter>

        = ;  <parameter>Depth=3D11.8 mi.</parameter>

        = ;  <parameter>Quality=3DExcellent</parameter>

        = ;  <area>       

        = ;        <areaDesc>1 mi. WSW of Brawley, CA; 11 mi. N of El Centro, CA; 30 = mi. E of OCOTILLO (quarry); 1 mi. N of the Imperial = Fault</areaDesc>

        = ;        = <circle>32.9525,-115.5527 0</circle>  

        = ;  </area>

   = </info>

</alert>

 

 

------=_NextPart_000_004B_01C4F648.AE5B1720-- From owner-atom-syntax@mail.imc.org Sun Jan 9 13: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 NAA27425 for ; Sun, 9 Jan 2005 13:10: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 j09HvmQs059602; Sun, 9 Jan 2005 09:57: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 j09Hvmv9059601; Sun, 9 Jan 2005 09:57:48 -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 j09Hvmk1059580 for ; Sun, 9 Jan 2005 09:57:48 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 48306 invoked by uid 17064); 9 Jan 2005 17:57:51 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.253.244.215]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 9 Jan 2005 17:57:51 -0000 In-Reply-To: <1f2ed5cd0501081403144e7bc6@mail.gmail.com> References: <1f2ed5cd0501081403144e7bc6@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: rubys@intertwingly.net, Tim.Bray@Sun.COM, phoffman@imc.org, atom-syntax@imc.org From: Henry Story Subject: Re: Comment on process Date: Sun, 9 Jan 2005 18:57:26 +0100 To: Danny Ayers X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I would like to agree with this. I have not had much of a weekend, and I am not sure I will be able to take so much time off work to put into this task. I am being paid to work on an open source blog editor, and I am not sure its ok for me to just spend all my time on this list. Also the proposal I put forward in the "Closure on Extensibility & RDF" thread is itself really a process. I outlined 4 steps to test out my idea. I do not know if it will succeed, just that it would be very elegant if it did. It would help if some more experienced people than me put their head together to help out this process. But my feeling is that they won't bother if they feel that the opening was a sham one. Nobody wants to waste their time. So that is why I asked for a little good will. And I don't think that there should be any bad will, since what I am proposing should have very little impact on what those that don't want to know about RDF want. Henry On 8 Jan 2005, at 23:03, Danny Ayers wrote: > I'm not going to argue the point here any further, but feel something > has to be said. > > I am optimistic a compromise on the extensibility/RDF issue can be > reached in the given time frame, but find the imposition of such a > short period a bit extreme. It isn't that there hasn't been > considerable work on RDF-compatibility, that side's potentially > trivial (use RDF/XML!), it's the production of a compromise everyone > is comfortable with. From owner-atom-syntax@mail.imc.org Sun Jan 9 13:21: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 NAA27741 for ; Sun, 9 Jan 2005 13:21: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 j09I5LJb067906; Sun, 9 Jan 2005 10:05: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 j09I5LMw067905; Sun, 9 Jan 2005 10:05:21 -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 j09I5I8r067892 for ; Sun, 9 Jan 2005 10:05:18 -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 j09I5Kqr021371; Sun, 9 Jan 2005 13:05: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 CHS32345; Sun, 9 Jan 2005 13:05:20 -0500 (EST) Message-Id: <200501091805.CHS32345@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Eric Scheid'" , "'Atom Syntax'" Subject: RE: Signatures in feeds of Aggregated Entry Documents Date: Sun, 9 Jan 2005 13:05: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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcT2OLlDM8eXaG6OQxyDcc6sqWZHXAAOuwjw Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: > does the signature technology we use for the atom format allow us > to state that certain child elements are not to be included in > the signature algorithm? Yes, the signature specification provides for an XPath filter[1] to be defined that excludes flagged portions of the data from the signature. You may remember that we discussed this subject back in September[2] when I proposed that we require that signatures on Atom Entries should be required to include the following XPath filter element: .//*[@not-signed] Items added to entries after they are signed should be given a "not-signed" attribute. I gave an example of this in PaceHeadInEntry[3] where you will see "..." in the example. If all signatures on Atom entries include the filter above then you could add any content you wanted without interfering with the signature mechanism. Note: A signature on an Atom feed should *not* contain the XPath above. bob wyman [1] http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-XPath [2] http://www.imc.org/atom-syntax/mail-archive/msg09604.html http://www.imc.org/atom-syntax/mail-archive/msg09596.html [3] http://www.intertwingly.net/wiki/pie/PaceHeadInEntry From owner-atom-syntax@mail.imc.org Sun Jan 9 14:11: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 OAA29889 for ; Sun, 9 Jan 2005 14:11: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 j09Ix4uT099546; Sun, 9 Jan 2005 10: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 j09Ix4HH099544; Sun, 9 Jan 2005 10:59:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (bay101-dav9.bay101.hotmail.com [64.4.56.81]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j09Ix336099448 for ; Sun, 9 Jan 2005 10:59:03 -0800 (PST) (envelope-from mdierken@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 9 Jan 2005 10:59:00 -0800 Message-ID: Received: from 207.202.171.254 by BAY101-DAV9.phx.gbl with DAV; Sun, 09 Jan 2005 18:58:44 +0000 X-Originating-IP: [207.202.171.254] X-Originating-Email: [mdierken@hotmail.com] X-Sender: mdierken@hotmail.com From: "S. Mike Dierken" To: "Danny Ayers" , References: <1f2ed5cd0501090423219e8c42@mail.gmail.com> Subject: Re: Regarding Graphs Date: Sun, 9 Jan 2005 10:59:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-OriginalArrivalTime: 09 Jan 2005 18:59:00.0427 (UTC) FILETIME=[478219B0:01C4F67D] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > > > > ... > > > http://example.org/entry > > ... > > > > If resources are view as nodes, then http://example.org/feed has two > parents. The containment tree is violated. I'm pretty sure the discussion was related to the content of a single XML document instance, rather than to resources distributed across a network. Once a piece of software traverses outside of an XML document instance, it is no longer containment. > But many real-world data structures (like the Web) > don't fall neatly into trees or tables, and the more general graph can > be useful. I don't consider the Web a data structure. But that's more likely just a choice of wording. > XML can be used effectively for serialization formats, > pretty much irrespective of the data structure. But the syntax may get > ugly if the data model is too far removed from Tree. I think you've nailed the issue - serialization of structure .vs. markup of information. From owner-atom-syntax@mail.imc.org Sun Jan 9 14:26: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 OAA00480 for ; Sun, 9 Jan 2005 14:26: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 j09JHVke019301; Sun, 9 Jan 2005 11:17: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 j09JHVhe019299; Sun, 9 Jan 2005 11:17: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j09JHVDf019220 for ; Sun, 9 Jan 2005 11:17:31 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so8794rnz for ; Sun, 09 Jan 2005 11:17:31 -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=C9VqgkjRA51JdFAArWWGx8KBcfbSRIyJuhyTVZWllLwI4FdIe0zoZz5B/NMERzQGjKvUXJM6bkB4860txX2F0mANCC9TDSTVC/CqZzj7hFnW2mL65Kf5M2nlHfS8J34heUAUhoiqO/dBAjZQOeM0uJbP5v3tKfLWVH8yuujooLs= Received: by 10.38.8.52 with SMTP id 52mr145009rnh; Sun, 09 Jan 2005 11:17:31 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sun, 9 Jan 2005 11:17:31 -0800 (PST) Message-ID: <1f2ed5cd0501091117646b2493@mail.gmail.com> Date: Sun, 9 Jan 2005 20:17:31 +0100 From: Danny Ayers Reply-To: Danny Ayers To: "S. Mike Dierken" Subject: Re: Regarding Graphs Cc: atom-syntax@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd0501090423219e8c42@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 9 Jan 2005 10:59:01 -0800, S. Mike Dierken wrote: > > > > > > > > > > ... > > > > > > http://example.org/entry > > > > ... > > > > > > > > If resources are view as nodes, then http://example.org/feed has two > > parents. The containment tree is violated. > > I'm pretty sure the discussion was related to the content of a single XML > document instance, rather than to resources distributed across a network. > Once a piece of software traverses outside of an XML document instance, it > is no longer containment. How about something like: ... http://example.org/entryA ... http://example.org/entryB ... Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sun Jan 9 15:22: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 PAA04601 for ; Sun, 9 Jan 2005 15:22: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 j09Jw5Zl031972; Sun, 9 Jan 2005 11:58: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 j09Jw5fg031971; Sun, 9 Jan 2005 11:58:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (bay101-dav17.bay101.hotmail.com [64.4.56.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j09Jw40U031953 for ; Sun, 9 Jan 2005 11:58:04 -0800 (PST) (envelope-from mdierken@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 9 Jan 2005 11:58:03 -0800 Message-ID: Received: from 207.202.171.254 by BAY101-DAV17.phx.gbl with DAV; Sun, 09 Jan 2005 19:57:09 +0000 X-Originating-IP: [207.202.171.254] X-Originating-Email: [mdierken@hotmail.com] X-Sender: mdierken@hotmail.com From: "S. Mike Dierken" To: "Danny Ayers" Cc: References: <1f2ed5cd0501090423219e8c42@mail.gmail.com> <1f2ed5cd0501091117646b2493@mail.gmail.com> Subject: Re: Regarding Graphs Date: Sun, 9 Jan 2005 11:57:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-OriginalArrivalTime: 09 Jan 2005 19:58:03.0723 (UTC) FILETIME=[877A29B0:01C4F685] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > How about something like: > > > ... > > http://example.org/entryA > > ... > > > http://example.org/entryB > > ... > > Maybe if you had the following instance you might be able to say one document is a graph. Otherwise you just have three resources (including the example itself as an un-identified resource) and even then http://example.org/entryA might or might not reference back into the un-identified resource (that the example xml comes from). I really didn't mean to sidetrack the original discussion. These are not the droids you're looking for. Nothing to see here. Move along. From owner-atom-syntax@mail.imc.org Sun Jan 9 15:22: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 PAA04619 for ; Sun, 9 Jan 2005 15:22: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 j09K2WjX032993; Sun, 9 Jan 2005 12:02: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 j09K2WOj032991; Sun, 9 Jan 2005 12:02:32 -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 j09K2VXR032979 for ; Sun, 9 Jan 2005 12:02:32 -0800 (PST) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id 67C6E4F0D2; Sun, 9 Jan 2005 15:02:35 -0500 (EST) Date: Sun, 9 Jan 2005 15:02:35 -0500 From: Dan Brickley To: Bob Wyman Cc: "'Tim Bray'" , "'Atom WG'" Subject: Re: The Atom Format end-game (PICS)?? Message-ID: <20050109200235.GE29340@homer.w3.org> References: <200501090642.CHQ51878@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501090642.CHQ51878@ms8.netsolmail.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: * Bob Wyman [2005-01-09 01:42-0500] > > Tim Bray wrote: > > 2. We are close to RSS2 feature-compatibility, we either adopt > > image & enclosure or make a conscious decision not to. > There are other bits of RSS2 that should be seriously considered -- > even if they aren't widely used. For instance, the RSS2 element > which contains a PICS[1] statement. As far as I know, virtually noone uses > the tag in RSS2.0. Nonetheless, it would probably be wise to > support such a thing in Atom. As blogging goes "mainstream," we should be > able to show that mechanisms at least exist to do what PICS is attempting to > do... I agree that it should be possible to do PICS-like stuff in RSS and Atom feeds. I'm not sure you need a PICS tag in the core spec though. Various folks in Europe and Japan (eg. ICRA, IAJapan) are looking into PICS-like functionality in an RDF and XML environment, with use cases that go somewhat beyond the classic filtering / 'child protection' scenarios that dominate public perception of PICS. Historical aside, the original name for RDF was PICS-NG, an effort which was merged with Guha and TimBray's MCF-in-XML ideas. I'd argue that any PICS-ish functionality in 2005 can be accomplished using namespaces, and probably using RDF/XML-oriented namespaces, and that PICS itself is a legacy that doesn't need to be supported in the core Atom format. Of course if there are folks out there who really want to produce and consume PICS s-expression syntax in feeds, they can invent a namespace'd construct that allows such embedding. There are actually a few things PICS can do which XML and even RDF/OWL don't do well yet, in particular the ability to write a content label with a rule that explains how it applies to all documents that share a common base URI. But some of are working on an XML/RDF-ization of this. Details hopefully to follow soonish... Dan > bob wyman > > [1] http://www.w3.org/PICS/ > From owner-atom-syntax@mail.imc.org Sun Jan 9 15:25: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 PAA04688 for ; Sun, 9 Jan 2005 15:25: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 j09K4Vu1033493; Sun, 9 Jan 2005 12:04: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 j09K4VuJ033492; Sun, 9 Jan 2005 12:04: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 j09K4UWs033480 for ; Sun, 9 Jan 2005 12:04:30 -0800 (PST) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id A50AD4F041; Sun, 9 Jan 2005 15:04:34 -0500 (EST) Date: Sun, 9 Jan 2005 15:04:34 -0500 From: Dan Brickley To: Danny Ayers Cc: bob@wyman.us, Tim Bray , Atom WG Subject: Re: The Atom Format end-game (PICS)?? Message-ID: <20050109200434.GF29340@homer.w3.org> References: <200501090642.CHQ51878@ms8.netsolmail.com> <1f2ed5cd05010905387111e8ea@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1f2ed5cd05010905387111e8ea@mail.gmail.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: * Danny Ayers [2005-01-09 14:38+0100] > > On Sun, 9 Jan 2005 01:42:23 -0500, Bob Wyman wrote: > > > > Tim Bray wrote: > > > 2. We are close to RSS2 feature-compatibility, we either adopt > > > image & enclosure or make a conscious decision not to. > > There are other bits of RSS2 that should be seriously considered -- > > even if they aren't widely used. For instance, the RSS2 element > > which contains a PICS[1] statement. As far as I know, virtually noone uses > > the tag in RSS2.0. Nonetheless, it would probably be wise to > > support such a thing in Atom. As blogging goes "mainstream," we should be > > able to show that mechanisms at least exist to do what PICS is attempting to > > do... > > The PICS material itself seems very dusty, but ratings came up on the > rss-media@yahoo list and the following links were dropped in: > > http://www.icra.org/vocabulary/ > http://www.icra.org/projects/quatro/ > > The fact that the issue was raised on a list related to Yahoo's media > search services does suggest that something like this will be needed > in the not-too-distant future. Yeah, that's one of the projects I mentioned (and which currently pays for me, via ERCIM, W3C's European host, btw). I have to review some new drafts RSN. The basic idea is to finish the technical migration of PICS stuff to the RDF world, and apply it to quality ratings etc rather than just filtering. I'll try to get a feed set up for the project so folks here can keep an eye on us... cheers, Dan From owner-atom-syntax@mail.imc.org Sun Jan 9 16: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 QAA07808 for ; Sun, 9 Jan 2005 16: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 j09L5f9b077170; Sun, 9 Jan 2005 13:05: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 j09L5fql077169; Sun, 9 Jan 2005 13:05:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nic-naa.net (nic-naa.net [216.220.241.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j09L5eHc077151 for ; Sun, 9 Jan 2005 13:05:41 -0800 (PST) (envelope-from brunner@nic-naa.net) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.13.1/8.13.1) with ESMTP id j09GhE06032933; Sun, 9 Jan 2005 16:43:14 GMT (envelope-from brunner@nic-naa.net) Message-Id: <200501091643.j09GhE06032933@nic-naa.net> To: Dan Brickley cc: Danny Ayers , bob@wyman.us, Tim Bray , Atom WG , brunner@nic-naa.net Subject: Re: The Atom Format end-game (PICS)?? In-Reply-To: Your message of "Sun, 09 Jan 2005 15:04:34 EST." <20050109200434.GF29340@homer.w3.org> Date: Sun, 09 Jan 2005 16:43:14 +0000 From: Eric Brunner-Williams in Portland Maine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Really? I'd no idea anyone was working on PICS, or had since ... I started on P3P, circa 1999. Add me please to your mildly-interested list. TiA, Eric From owner-atom-syntax@mail.imc.org Sun Jan 9 17:29: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 RAA11446 for ; Sun, 9 Jan 2005 17:29: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 j09M7kRv007887; Sun, 9 Jan 2005 14:07: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 j09M7k2n007886; Sun, 9 Jan 2005 14:07: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 j09M7jwT007871 for ; Sun, 9 Jan 2005 14:07: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 1CnlDV-0003z6-UI; Sun, 09 Jan 2005 22:07:22 +0000 Message-ID: <41E1AB29.5030400@franklinmint.fm> Date: Sun, 09 Jan 2005 17:07:37 -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: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom WG Subject: Re: Hash for Links [Was: Re: Posted PaceEnclosuresAndPix] References: <1f2ed5cd050105162514f7773f@mail.gmail.com> <1f2ed5cd050106050455c75c9d@mail.gmail.com> <2bcdc7c405010609374df235f3@mail.gmail.com> <41E01953.7030404@dehora.net> <41E03C53.1000701@franklinmint.fm> <2bcdc7c405010818143d6ab41d@mail.gmail.com> In-Reply-To: <2bcdc7c405010818143d6ab41d@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: >I really don't want to be going down the road of requiring HTTP header >equivalents in the Atom feed, etc. All I want is the ability to >specify a hash of whatever it is that is being linked to. It could >work in both link and content elements and one could easily use the >Content-MD5 header to verify whether or not the resource referenced >has been modified since the time it was included in the Entry. > >The URI and the length of the file do not guarantee that the content >has not changed and yes, I had considered this as a possible non-core >extension but wanted to float it as a core item first. > > The level of accuracy you're looking for can't be achieved without specifying which HTTP request headers can influence the content returned (e.g. "Accept"), and what their values must be in order to receive the content with the hash given. For example, content negotiation could be really handy for podcasts (mp3, aac, ogg, wma). Robert Sayre From owner-atom-syntax@mail.imc.org Sun Jan 9 18:37: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 SAA16023 for ; Sun, 9 Jan 2005 18: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 j09NL0E5030925; Sun, 9 Jan 2005 15:21: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 j09NL0hV030924; Sun, 9 Jan 2005 15:21:00 -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 j09NL0nW030896 for ; Sun, 9 Jan 2005 15:21:00 -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 <20050109232058.BRG21886.fed1rmmtao07.cox.net@[192.168.0.100]>; Sun, 9 Jan 2005 18:20:58 -0500 In-Reply-To: <1f2ed5cd0501090423219e8c42@mail.gmail.com> References: <1f2ed5cd0501090423219e8c42@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1D065342-6295-11D9-B5EE-000D93324AD6@gbiv.com> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org From: "Roy T. Fielding" Subject: Re: Regarding Graphs Date: Sun, 9 Jan 2005 15:20:56 -0800 To: Danny Ayers X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 9, 2005, at 4:23 AM, Danny Ayers wrote: > There were a couple of points made in recent discussions that might > have been misleading. One was that Atom is a tree. The XML may use > that structure, and in it's simplest form the information being > represented may be tree-shaped, but that isn't necessary the case. No, the element containment hierarchy that establishes default relationships between data and metadata is a tree. > For example: > > > > > ... > > > http://example.org/entry > > ... > > > > If resources are view as nodes, then http://example.org/feed has two > parents. The containment tree is violated. Nonsense. The containment tree tells us what the tail of the link is, not the target of those links. The information is going to have far more relationships just by virtue of the content text, and thus the information will be a graph even if the relations are not made explicit via links. Their containment is only a very small subset of those relationships and cannot be violated by the mere presence of other types of links. The reason this topic came up was because people wanted to know how the format is extensible given the implicit relationship between feed, entry, and entry elements. Containment is the only answer needed because all other relationships are explicitly targeted by a URI. Personally, what I would change in the format is elimination of head and make feed a recursive element. Then there would be no doubt as to the hierarchical relations and feed vacuums can compose multiple feeds to their heart's delight without changing the entries at all. ....Roy From owner-atom-syntax@mail.imc.org Sun Jan 9 18:52: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 SAA17067 for ; Sun, 9 Jan 2005 18: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 j09NcXuB032902; Sun, 9 Jan 2005 15:38: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 j09NcXVp032901; Sun, 9 Jan 2005 15:38:33 -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 j09NcXKY032894 for ; Sun, 9 Jan 2005 15:38:33 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 45320 invoked by uid 17064); 9 Jan 2005 23:38:38 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.253.244.215]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 9 Jan 2005 23:38:38 -0000 In-Reply-To: <1D065342-6295-11D9-B5EE-000D93324AD6@gbiv.com> References: <1f2ed5cd0501090423219e8c42@mail.gmail.com> <1D065342-6295-11D9-B5EE-000D93324AD6@gbiv.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <88A8058B-6297-11D9-8C94-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Danny Ayers , atom-syntax@imc.org From: Henry Story Subject: Re: Regarding Graphs Date: Mon, 10 Jan 2005 00:38:15 +0100 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Well on this one at least we have some agreement. I have been arguing that for reasons of elegance for some time now that feed should be a subclass of Entry [1], and recently that the head is really hardly any different from an Entry [2]. But my Pace never seems to have got picked up in the editorial process. Henry Story [1] see the UML diagrams here http://www.imc.org/atom-syntax/mail-archive/msg04494.html [2] http://www.intertwingly.net/wiki/pie/PaceEntriesAllTheWayDown2 On 10 Jan 2005, at 00:20, Roy T. Fielding wrote: > > Personally, what I would change in the format is elimination > of head and make feed a recursive element. Then there would be > no doubt as to the hierarchical relations and feed vacuums can > compose multiple feeds to their heart's delight without changing > the entries at all. > > ....Roy From owner-atom-syntax@mail.imc.org Sun Jan 9 19: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 TAA17952 for ; Sun, 9 Jan 2005 19: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 j09NsDZA036099; Sun, 9 Jan 2005 15:54: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 j09NsD4Y036098; Sun, 9 Jan 2005 15:54: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 j09NsCDx036092 for ; Sun, 9 Jan 2005 15:54:12 -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 1Cnmse-0005m4-Lq; Sun, 09 Jan 2005 23:53:56 +0000 Message-ID: <41E1C427.50906@franklinmint.fm> Date: Sun, 09 Jan 2005 18:54:15 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bobwyman@pubsub.com CC: "'Atom Syntax'" Subject: Re: Signatures in feeds of Aggregated Entry Documents References: <20050109044141.21BCB72412E@mail.pubsub.com> In-Reply-To: <20050109044141.21BCB72412E@mail.pubsub.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: > I can't remember if this has been discussed before. I'm tempted to write a > >Pace which would specify that any atom:entry can be signed - whether it is >found in an Atom Feed Document or an Atom Entry Document. Before doing so, I >would appreciate if someone could explain if the constraint in the current >specification is intentional. Why would a signature not be permitted on an >atom:entry found in an Atom Feed Document? > > I don't know if the constraint was intentional. At the time, I just wrote down what Mark P. and Paul told me to (PaceDigitalSignatures), but I wrote a little command line program with Apache XMLSec today, and it wasn't very difficult (I'll publish the source soon). I looked around a bit today, so the following are the findings of a non-expert. MustIgnore should let you put a DSig element anywhere you want, but I don't think we can reasonably require an XPath Filter. Xpath is not a MUST[0], and not all implementations allow it[1]. Also, the DSig people have come up with a new XPath filter that allows greatly increased performance[2], and very few implementations support that[3]. That leaves us with the possibility of specifying how to sign an entry that allows unsigned mangling, but not requiring it. I think there's also the question of whether a feed signature includes the DSig elements that appear within it. We can probably strike the following: "Other elements in an Atom document MUST NOT be signed unless their definitions explicitly specify such a capability." if we gain mustIgnore text (I think this should be uncontroversial). Robert Sayre [0] http://www.w3.org/TR/xmldsig-core/#sec-TransformAlg [1] http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html [2] http://www.w3.org/TR/xmldsig-filter2/ [3] http://www.w3.org/Signature/2002/05/xmldsig-filter2-interop.html From owner-atom-syntax@mail.imc.org Sun Jan 9 19: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 TAA19074 for ; Sun, 9 Jan 2005 19: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 j0A0KW0C042683; Sun, 9 Jan 2005 16:20: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 j0A0KW3L042682; Sun, 9 Jan 2005 16:20:32 -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 j0A0KSUx042672 for ; Sun, 9 Jan 2005 16:20:28 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 90296 invoked by uid 17064); 10 Jan 2005 00:20:33 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.253.244.215]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 10 Jan 2005 00:20:33 -0000 In-Reply-To: <41DEF794.5050707@franklinmint.fm> References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <41DEF794.5050707@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <63C87CE6-629D-11D9-8C94-000A95D9FA7A@bblfish.net> Cc: atom-owl@googlegroups.com, "'Atom WG'" From: Henry Story Subject: Atom Link element Date: Mon, 10 Jan 2005 01:20:10 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0A0KSUx042673 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 7 Jan 2005, at 21:56, Robert Sayre wrote: > Henry Story wrote: > >> The question is exactly how should the interesting discovery that an >> Atom document is an RDF document [Ø] be used to fulfill the charter >> requirements on extensibility? > > Have you figured out a way to deal with this: > Thanks for the question. Let me try the mapping from a graph representing that link to the atom xml syntax. Here is how I would model that link. _e2 --a-----> |---link---> _l2 ---- a ---> |--hreflang --> "de"^^xsd:language |--href-> "http://example.org/de/2003/12/13/Atom03"^^xsd:anyURI Then I we can follow the recipe [1] to reach our goal 1) Striped RDF/XML + combining multiple descriptions ----------------------------------------------------                                               de       http://example.org/de/2003/12/13/Atom03    2) replacing empty property elements with rdf:resource ------------------------------------------------------                      de       http://example.org/de/2003/12/13/Atom03    3) Entry Typed Node Element transformation ------------------------------------------               de       http://example.org/de/2003/12/13/Atom03    4) Omitting the Link blank node -------------------------------          de       http://example.org/de/2003/12/13/Atom03    4) Property attributes ---------------------- both hreflang, href and all the other properties of Link are unique, and given that they are string literals (subsets of them at least, but nevertheless) they can be move into attributes on Link    5) getting rid of the rdf:parseType ----------------------------------- This can be done I have been told in the DTD.    Henry Story [1] http://www.w3.org/TR/rdf-syntax-grammar/ >> So perhaps we can open this thread as a place to post ideas on the >> topic. > > > I think the debate is pretty much settled for client GUI software. RDF > doesn't help a bit. A more interesting situation is a server receiving > Atom entries to publish. For the purposes of discussion, let's say the > server trusts the client. I am writing GUI based client software, and I am really looking forward to disprove your statement. > > It gets a POST with a fairly average atom entry, but there are > extensions in funny places. Like most people, the server stores > standard fields in a relational database, so there are columns for > title, summary, etc. in a table called something like > "journal_entries". It would be fairly easy to store immediate children > of entry in an "unknown_xml" field, and pass them through, but what > about the other extensions? Using an RDF store might make this problem > a lot easier, but I don't forsee a mass migration in that direction > happening this year or next. You don't need a specialized RDF storage, though very good ones exist. There are schemes to map RDF into any relational database, just as there are schemes to map objects into relational databases. In fact most RDF storage tools in Java provide this. > POST ... > > > My cat > > me > adfadf > > I took my cat on vacation > It was really fun > adfadsfa > > ... > > > > So, what's the algorithm and storage strategy that will allow maximum > extensibility but not require servers to re-architect? > > Robert Sayre > From owner-atom-syntax@mail.imc.org Sun Jan 9 19:40: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 TAA19287 for ; Sun, 9 Jan 2005 19:40: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 j0A0Th6R043616; Sun, 9 Jan 2005 16:29: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 j0A0Th4g043615; Sun, 9 Jan 2005 16:29: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 j0A0Tg6r043595 for ; Sun, 9 Jan 2005 16:29: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 1CnnR0-0006Ll-GJ; Mon, 10 Jan 2005 00:29:26 +0000 Message-ID: <41E1CC79.9070508@franklinmint.fm> Date: Sun, 09 Jan 2005 19:29:45 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Story CC: atom-owl@googlegroups.com, "'Atom WG'" Subject: Re: Atom Link element References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <41DEF794.5050707@franklinmint.fm> <63C87CE6-629D-11D9-8C94-000A95D9FA7A@bblfish.net> In-Reply-To: <63C87CE6-629D-11D9-8C94-000A95D9FA7A@bblfish.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 Henry Story wrote: > On 7 Jan 2005, at 21:56, Robert Sayre wrote: > >> Henry Story wrote: >> >>> The question is exactly how should the interesting discovery that >>> an Atom document is an RDF document [Ø] be used to fulfill the >>> charter requirements on extensibility? >> >> >> Have you figured out a way to deal with this: >> > ... > > > 4) Property attributes > ---------------------- > > both hreflang, href and all the other properties of Link are unique, > and given that they are string literals (subsets of them at least, > but nevertheless) they can be move into attributes on Link > > > hreflang="de" href="http://example.org/de/2003/12/13/Atom03"/> > Use of unqualified attributes is deprecated in RDF/XML (check the validator). My opinion is that the transformation you're looking for would be easier with XSLT. >> >> >> I think the debate is pretty much settled for client GUI software. >> RDF doesn't help a bit. A more interesting situation is a server >> receiving Atom entries to publish. For the purposes of discussion, >> let's say the server trusts the client. > > > I am writing GUI based client software, and I am really looking > forward to disprove your statement. > Cool. That's the only way to disprove it ;) >> >> It gets a POST with a fairly average atom entry, but there are >> extensions in funny places. Like most people, the server stores >> standard fields in a relational database, so there are columns for >> title, summary, etc. in a table called something like >> "journal_entries". It would be fairly easy to store immediate >> children of entry in an "unknown_xml" field, and pass them through, >> but what about the other extensions? Using an RDF store might make >> this problem a lot easier, but I don't forsee a mass migration in >> that direction happening this year or next. > > > You don't need a specialized RDF storage, though very good ones > exist. There are schemes to map RDF into any relational database, > just as there are schemes to map objects into relational databases. > In fact most RDF storage tools in Java provide this. That's not my point. My point is that there's a staggering amount of data currently living in RDBMSes, and people aren't going to re-architect their storage to use Atom. Robert Sayre From owner-atom-syntax@mail.imc.org Sun Jan 9 19:46: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 TAA19522 for ; Sun, 9 Jan 2005 19: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 j0A0aBAl044742; Sun, 9 Jan 2005 16:36: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 j0A0aBLG044741; Sun, 9 Jan 2005 16:36:11 -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 j0A0aBsC044725 for ; Sun, 9 Jan 2005 16:36:11 -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 <20050110003610.ZZTN17071.fed1rmmtao06.cox.net@[192.168.0.100]> for ; Sun, 9 Jan 2005 19:36:10 -0500 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <9C395894-629F-11D9-B5EE-000D93324AD6@gbiv.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Atom WG From: "Roy T. Fielding" Subject: PaceFeedRecursive Date: Sun, 9 Jan 2005 16:36:04 -0800 X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I just created a starting point for a proposal on making the feed element recursive, eliminating the need for RDF syntax, atom:head, and a bunch of things proposed in other paces regarding aggregators and digital signatures. http://www.intertwingly.net/wiki/pie/PaceFeedRecursive Unfortunately, I have a paper deadline on Tuesday and can't procrastinate any longer, so someone else can finish the details or I'll finish it later in the week. Cheers, Roy T. Fielding Chief Scientist, Day Software From owner-atom-syntax@mail.imc.org Sun Jan 9 20:56: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 UAA23815 for ; Sun, 9 Jan 2005 20:56: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 j0A1e3IA005141; Sun, 9 Jan 2005 17: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 j0A1e3B1005140; Sun, 9 Jan 2005 17: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 ([161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0A1e2WV004315 for ; Sun, 9 Jan 2005 17: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 j0A1c8ad012380; Mon, 10 Jan 2005 01:38:13 GMT In-Reply-To: <9C395894-629F-11D9-B5EE-000D93324AD6@gbiv.com> References: <9C395894-629F-11D9-B5EE-000D93324AD6@gbiv.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-12-312353436; protocol="application/pkcs7-signature" Message-Id: <47FF7A4B-62A8-11D9-B651-000A95DC3D90@mac.com> Cc: Atom WG From: Graham Subject: Re: PaceFeedRecursive Date: Mon, 10 Jan 2005 01:38:08 +0000 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619) 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-312353436 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit -1; Conceptual masturbation. Graham --Apple-Mail-12-312353436 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 9w0BCQUxDxcNMDUwMTEwMDEzODA4WjAjBgkqhkiG9w0BCQQxFgQUfYwagbOk1O37TCruJRoqJKfc p4QweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAQKGmaJun737R5NqaI8fj7CPW Gbbj7h3fLc/k0HGNnDMXgkNABbt+1NmDNdIrTeEL1kBkcg68MGJo4AjjAtZYI51Kv54jU37abhDl mMJAN7oHqANT0NXvAGC/OpztfXk9OlHnSvumV0hgiTRBaOvIljLYx1DmCh+V9ykckDNUxTXRm23Z 2nTytTD32JoWCwSh8wjX3GHAlIvGHzW/oF2Rd0HQezvKYcrkLarJAZCGGzAeYeUL1XXDoZzj//Qb CUuw9AHnDYcNpRawuyTDfnUJs26YrECNeNH8IE5qyR6DVCnjiA66mFn/JAntKV+k8XCNgcU3CFnN 3VHtueClWJcxkAAAAAAAAA== --Apple-Mail-12-312353436-- From owner-atom-syntax@mail.imc.org Sun Jan 9 23:24: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 XAA01806 for ; Sun, 9 Jan 2005 23:24: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 j0A4Apnj009940; Sun, 9 Jan 2005 20:10: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 j0A4Aplg009939; Sun, 9 Jan 2005 20:10:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao10.cox.net (fed1rmmtao10.cox.net [68.230.241.29]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0A4Ap7X009807 for ; Sun, 9 Jan 2005 20:10:51 -0800 (PST) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao10.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050110041053.PQGL7026.fed1rmmtao10.cox.net@[192.168.0.100]>; Sun, 9 Jan 2005 23:10:53 -0500 In-Reply-To: <47FF7A4B-62A8-11D9-B651-000A95DC3D90@mac.com> References: <9C395894-629F-11D9-B5EE-000D93324AD6@gbiv.com> <47FF7A4B-62A8-11D9-B651-000A95DC3D90@mac.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9D5C34FE-62BD-11D9-B5EE-000D93324AD6@gbiv.com> Content-Transfer-Encoding: 7bit Cc: Atom WG From: "Roy T. Fielding" Subject: Re: PaceFeedRecursive Date: Sun, 9 Jan 2005 20:10:51 -0800 To: Graham X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 9, 2005, at 5:38 PM, Graham wrote: > -1; Conceptual masturbation. Wow, you like it that much? It must be a really good idea, then, since we are all just doing this to keep you stimulated. ....Roy From owner-atom-syntax@mail.imc.org Mon Jan 10 06:49: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 GAA11613 for ; Mon, 10 Jan 2005 06: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 j0ABVOM8032441; Mon, 10 Jan 2005 03:31: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 j0ABVNi4032440; Mon, 10 Jan 2005 03:31: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.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0ABVFd0032374 for ; Mon, 10 Jan 2005 03:31:15 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so37645rnz for ; Mon, 10 Jan 2005 03:31: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=QlEW2nMOx0XXp3WKbq1GGxDQF7l/NvGcsRSqWwFaJm8p/Gmq2GWnvt/YYSn9LGmAuECU62SYLa64YLBdetzPZudqKcBVJ/XXC3ZQLGFHRlKcqKEcUf8QnmINWenfrnDdwcGl7St5ID9kOTvCnEnfce7EdC6WfjiJM2sy9vyDlTg= Received: by 10.38.206.12 with SMTP id d12mr1214909rng; Mon, 10 Jan 2005 03:31:16 -0800 (PST) Received: by 10.38.179.71 with HTTP; Mon, 10 Jan 2005 03:31:16 -0800 (PST) Message-ID: <1f2ed5cd050110033163836ec5@mail.gmail.com> Date: Mon, 10 Jan 2005 12:31:16 +0100 From: Danny Ayers Reply-To: Danny Ayers To: "Roy T. Fielding" Subject: Re: Regarding Graphs Cc: atom-syntax@imc.org In-Reply-To: <1D065342-6295-11D9-B5EE-000D93324AD6@gbiv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd0501090423219e8c42@mail.gmail.com> <1D065342-6295-11D9-B5EE-000D93324AD6@gbiv.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 9 Jan 2005 15:20:56 -0800, Roy T. Fielding wrote: > > For example: > > > > > > > > > > ... > > > > > > http://example.org/entry > > > > ... > > > > > > > > If resources are view as nodes, then http://example.org/feed has two > > parents. The containment tree is violated. > > Nonsense. The containment tree tells us what the tail of the link > is, not the target of those links. The information is going to > have far more relationships just by virtue of the content text, > and thus the information will be a graph even if the relations > are not made explicit via links. Well yes, that was really what I was trying to say, that there are more relationships than those expressed by the tree. Their containment is only a > very small subset of those relationships and cannot be violated > by the mere presence of other types of links. If you restrict the set of entities and relationships under discussion to those directly involved in containment relationships, then sure, containment will not be violated. > The reason this topic came up was because people wanted to > know how the format is extensible given the implicit relationship > between feed, entry, and entry elements. Containment is the only > answer needed because all other relationships are explicitly > targeted by a URI. Other relationships can be targetted by a URI, and this with containment can be enough to describe all the relationships needed. But my original point was that it wasn't being made explicit. > Personally, what I would change in the format is elimination > of head and make feed a recursive element. Then there would be > no doubt as to the hierarchical relations and feed vacuums can > compose multiple feeds to their heart's delight without changing > the entries at all. I think this approach was suggested fairly early on, I'm not sure why it didn't make it through, possibly the argument that flatter is simpler (for non-Functional developers). The (recursive) nesting approach can certainly work well, I've seen striped RDF/XML that looks like this, even the overstretched OPML (sometimes) works because of it. I'm not sure how you'd deal with multiple occurrences of the same entry/feed in different layers. I suppose they could be referred to through their URIs. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Mon Jan 10 06:51: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 GAA11670 for ; Mon, 10 Jan 2005 06:51: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 j0ABhpWE037675; Mon, 10 Jan 2005 03:43: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 j0ABhpPH037674; Mon, 10 Jan 2005 03:43:51 -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 j0ABhoBE037650 for ; Mon, 10 Jan 2005 03:43:50 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so37975rnz for ; Mon, 10 Jan 2005 03:43: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=sF+TCajZX1ZtlVSV5TKwW2dcLsLh/DhL7vF3ePHyXjfisgkz7UeJFnYYqOXp2uwvG9i6rjCKAxgtxgo12h8ewIIONsyYz7ag/PMWe1Lcz4/b2MQ3IR0A37+igK9dDhs4VZL2Q1xxDKJrigYFs4fRVICCzRjOEnBUQniRtijsHBw= Received: by 10.38.206.12 with SMTP id d12mr1217727rng; Mon, 10 Jan 2005 03:43:48 -0800 (PST) Received: by 10.38.179.71 with HTTP; Mon, 10 Jan 2005 03:43:48 -0800 (PST) Message-ID: <1f2ed5cd0501100343334d0bec@mail.gmail.com> Date: Mon, 10 Jan 2005 12:43:48 +0100 From: Danny Ayers Reply-To: Danny Ayers To: "Roy T. Fielding" Subject: Re: PaceFeedRecursive Cc: Atom WG In-Reply-To: <9C395894-629F-11D9-B5EE-000D93324AD6@gbiv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <9C395894-629F-11D9-B5EE-000D93324AD6@gbiv.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 9 Jan 2005 16:36:04 -0800, Roy T. Fielding wrote: > http://www.intertwingly.net/wiki/pie/PaceFeedRecursive I like it, but seem to remember a similar proposal being rejected - anyone..? This approach should be pretty straightforward to program against, and what's more should offer easy processing/data access through XSLT/XQuery and simple mapping to RDF (essentially using striped RDF/XML). The only issue that springs to mind is that a feed could end up with a huge amount of redundant chars if the same feeds/entries appeared multiple times in different branches of the hierarchy. A simple mechanism for substituting a feed/entry with its URI might do, or alternately an in-document #id kind of cross reference to the first occurence of the feed entry. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Mon Jan 10 07:40: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 HAA14560 for ; Mon, 10 Jan 2005 07:40: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 j0ACQG9f061925; Mon, 10 Jan 2005 04: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 j0ACQGbs061924; Mon, 10 Jan 2005 04:26: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 j0ACQG0x061879 for ; Mon, 10 Jan 2005 04:26:16 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so39456rnz for ; Mon, 10 Jan 2005 04:26: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=Ii+oVj+efBwBqYGXtX3nF+pGNhUonFEW4mllkScno4fI254o2V3sBFrATIIF7m33eSjgJqFDLOzfnwCJrGSRkvRmHD45ojl7CGPbjUkzFRWdqXS59+5aMknc6Ym6NIuBqUXjzohWF/FidlX6GP0Ueu8MXEOiqIAQ1w28wj6EPUM= Received: by 10.38.179.15 with SMTP id b15mr324565rnf; Mon, 10 Jan 2005 04:26:12 -0800 (PST) Received: by 10.38.179.71 with HTTP; Mon, 10 Jan 2005 04:26:12 -0800 (PST) Message-ID: <1f2ed5cd05011004262ea8b9bf@mail.gmail.com> Date: Mon, 10 Jan 2005 13:26:12 +0100 From: Danny Ayers Reply-To: Danny Ayers To: atom-owl@googlegroups.com Subject: Re: Atom Link element Cc: Henry Story , Atom WG In-Reply-To: <41E1CC79.9070508@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <41DEF794.5050707@franklinmint.fm> <63C87CE6-629D-11D9-8C94-000A95D9FA7A@bblfish.net> <41E1CC79.9070508@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 09 Jan 2005 19:29:45 -0500, Robert Sayre wrote: To jump in late on - > That's not my point. My point is that there's a staggering amount of > data currently living in RDBMSes, and people aren't going to > re-architect their storage to use Atom. True, but they don't have to. Taking the RDF case (as something the far side of Atom+extensions), it's reasonably straightforward to project RDBMS data as triples, such as RDF/XML and the representation of n-ary relations is quite well documented (e.g. [1]). SQL views are *very* handy. (Incidentally a simple way of re-architecting would be to replace existing tables with views that have exactly the same layout, projected from a triple store/table). But that's just working on material that's already in the existing domain of the RDBMS. Where it gets more interesting is with (potentially unknown) extensions. I reckon it's entirely feasible to use a triplestore for these bits, leaving the core work to conventional (existing) tables. Somewhere around the middle of my to-do list is to take one of the open source CMSs and add FOAF support. It's easy to imagine a separate, bolted on RDF store, perhaps using a three-column table in the existing database. But the tricky (i.e. interesting) part is how to integrate existing user handling - usernames, access rights etc - with the new store. I think the simplest approach would be to cleanly isolate the existing 'username' tables (if necessary) then swap those tables out for SQL views of a triple table. I've tried stuff similar to this, and it's pretty straightforward. What would be better still would be to leave the existing tables entirely in place, and use joins between those tables and the triple store. I'm not entirely sure how much work would be involved with this approach, having yet to experiment. I reckon in general that the fact that both the RDBMS and RDF are based on relational models, there's a wide band of overlap that can simplify interoperability. This isn't really the case with XML-oriented stores, RDF/XML being a bit of a red herring. It would be nice for Atom to get the best of both worlds. Cheers, Danny. [1] http://www.w3.org/TR/2004/WD-swbp-n-aryRelations-20040721/ -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Mon Jan 10 10:10: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 KAA24186 for ; Mon, 10 Jan 2005 10:10: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 j0AEtrDA004963; Mon, 10 Jan 2005 06:55: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 j0AEtriX004962; Mon, 10 Jan 2005 06:55:53 -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 j0AEtqdj004938 for ; Mon, 10 Jan 2005 06:55:52 -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 j0AEsK5B027732; Mon, 10 Jan 2005 14:54:25 GMT In-Reply-To: <9D5C34FE-62BD-11D9-B5EE-000D93324AD6@gbiv.com> References: <9C395894-629F-11D9-B5EE-000D93324AD6@gbiv.com> <47FF7A4B-62A8-11D9-B651-000A95DC3D90@mac.com> <9D5C34FE-62BD-11D9-B5EE-000D93324AD6@gbiv.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-14-360125179; protocol="application/pkcs7-signature" Message-Id: <822CE8FF-6317-11D9-B651-000A95DC3D90@mac.com> Cc: Atom WG From: Graham Subject: Re: PaceFeedRecursive Date: Mon, 10 Jan 2005 14:54:20 +0000 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619) 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-14-360125179 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 10 Jan 2005, at 4:10 am, Roy T. Fielding wrote: > On Jan 9, 2005, at 5:38 PM, Graham wrote: >> -1; Conceptual masturbation. > > Wow, you like it that much? It must be a really good idea, then, > since we are all just doing this to keep you stimulated. Sarcasm and everything. Wow. Seriously, though, all you've done is not bothered to flatten the data at any point. While this may please you, all it means is the software at the far end has to wade through a few more sets of angle brackets and implement a couple of stacks. Don't think for a second that your format contains more data that the current flat format, because since it's all implicit, it's worthless. If say, entries appear in two separate groups in a feed, it might mean that they came from separate sources, or it might nor it might not mean anything. Why not just make it explicit? Graham --Apple-Mail-14-360125179 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 9w0BCQUxDxcNMDUwMTEwMTQ1NDIwWjAjBgkqhkiG9w0BCQQxFgQUlCnMxClfFm4FaKq9Vm+BlKce A4MweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAfGLtbJSULZWiYjnteQV8Bfms BK/SVmbMvZx2gIGGS6ofbzU+CHBrqEvkf9mmsE2O438ZCCIT4J8FId1bG67T55rl3BsP8FxXDjiO /aL366Y09W909oWYw+FsP/5FeDBUya52zC90oH4WLeM7ZbWuzY/RyERuUVlUk0uZz6zsrAQpVVl8 hRcLy2Xfbb6G2hTmYMKNcI5++EfE6ubYyb9sr3QNj2wWw1l7yH0sm2xv0O0ARjVzJyz3UFTrm6CC 4NSTTA3PyqjLLkhMavqXSDv4V5z16Ts7dLauADfK/bMaP7CLhrRWtXs1GWy0FEYkB/iL39MSmrq8 QlpW3aSEaxLz7QAAAAAAAA== --Apple-Mail-14-360125179-- From owner-atom-syntax@mail.imc.org Mon Jan 10 11:33: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 LAA02586 for ; Mon, 10 Jan 2005 11:33: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 j0AGHgF9043368; Mon, 10 Jan 2005 08: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 j0AGHg1X043366; Mon, 10 Jan 2005 08:17:42 -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 j0AGHfb7043138 for ; Mon, 10 Jan 2005 08:17:41 -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 <2005011016173801200p8octe>; Mon, 10 Jan 2005 16:17:39 +0000 Date: Mon, 10 Jan 2005 09:17:37 -0700 Subject: Re: Signatures in feeds of Aggregated Entry Documents Content-Type: text/plain; delsp=yes; charset=WINDOWS-1252; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: <20050109044141.21BCB72412E@mail.pubsub.com> Message-Id: <2496ABA4-6323-11D9-A37A-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0AGHgb7043356 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Saturday, January 8, 2005, at 09:41 PM, Bob Wyman wrote: > As Robert Sayre recently wrote: > > >DSig and XMLEnc are in core. > > >http://atompub.org/2004/10/20/draft-ietf-atompub-format- > 03.html#rfc.section.7 > > However, the text says: > > “The document element of an Atom document (i.e., atom:feed in an Atom > Feed Document, atom:entry in an Atom Entry Document) MAY have an > Enveloped Signature” … “Other elements in an Atom document MUST NOT be > signed unless their definitions explicitly specify such a capability.” ... > I can’t remember if this has been discussed before. I’m tempted to > write a Pace which would specify that any atom:entry can be signed – > whether it is found in an Atom Feed Document or an Atom Entry > Document. Before doing so, I would appreciate if someone could explain > if the constraint in the current specification is intentional. Why > would a signature not be permitted on an atom:entry found in an Atom > Feed Document? > Might this constraint have grown out of http://www.imc.org/atom-syntax/mail-archive/msg09550.html - which I don't read as meaning what's in the current draft? Perhaps the original intent was to impose the following constraints, and the restriction on other elements being signed slipped in inadvertantly: * Document elements may only be signed using DSig. * Document elements may only use enveloped signatures (as opposed to enveloping, sibling...). and perhaps: * If other elements are signed, they must use enveloped signatures, unless their definitions explicitly specify a capability to use enveloping, etc., signatures. Thinking about it, I haven't been able to come up with a reason to forbid the signing of other elements, and I don't recall discussion of such a restriction either. From owner-atom-syntax@mail.imc.org Mon Jan 10 11:58: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 LAA04904 for ; Mon, 10 Jan 2005 11:58: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 j0AGm0CN082143; Mon, 10 Jan 2005 08:48: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 j0AGm0tp082141; Mon, 10 Jan 2005 08:48: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 j0AGlxGN082013 for ; Mon, 10 Jan 2005 08:47: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 (sccrmhc12) with SMTP id <2005011016475501200p7bu5e>; Mon, 10 Jan 2005 16:47:55 +0000 Date: Mon, 10 Jan 2005 09:47:53 -0700 Subject: Re: Signatures in feeds of Aggregated Entry Documents 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: <5F5C4BE4-6327-11D9-A37A-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, January 9, 2005, at 03:18 AM, Eric Scheid wrote: > sidebar: does the signature technology we use for the atom format > allow us > to state that certain child elements are not to be included in the > signature > algorithm. I'm thinking of something along the lines of the > following... > > > ... > > > > ... > > > > > > > This has come up before[1], but I don't think a Pace was ever written--a "not-signed" attribute seemed to be preferred early in the discussion. One drawback vs. a "not-signed" attribute is that applications would have to be able to recognize that 's children belong at the level where the annotation element itself lives. The obvious advantage of would be that the annotation itself could be signed, a la: ... ... could also be useful as a means of tracking where annotations to an entry came from. Only the original publisher might be allowed to add data outside of an annotation element. Applications merging entries might do so and put everything outside of annotation elements, but they could be required to generate a new ID for the entry, thus not asserting that it was an instance of one of the source entries. [1] http://www.imc.org/atom-syntax/mail-archive/msg09534.html From owner-atom-syntax@mail.imc.org Mon Jan 10 12:01: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 MAA05269 for ; Mon, 10 Jan 2005 12: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 j0AGnlLt083760; Mon, 10 Jan 2005 08:49: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 j0AGnlJf083759; Mon, 10 Jan 2005 08:49:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0AGnl70083666 for ; Mon, 10 Jan 2005 08:49:47 -0800 (PST) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by mail.pubsub.com (Postfix) with ESMTP id D0F947247A9; Mon, 10 Jan 2005 11:49:40 -0500 (EST) Reply-To: From: "Bob Wyman" To: "'Roy T. Fielding'" , "'Atom WG'" Subject: RE: PaceFeedRecursive Date: Mon, 10 Jan 2005 11:49:35 -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.5510 Thread-Index: AcT2rmmfzoVZGwWWRkOxQqBAXU826gAgMxLA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <9C395894-629F-11D9-B5EE-000D93324AD6@gbiv.com> Message-Id: <20050110164940.D0F947247A9@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roy T. Fielding wrote: > a proposal on making the feed element recursive Equivalent proposals have often been made in the past (sometimes by me!). These proposals fall in the category that we've come to know as "Feed of Feeds". Each time the proposal has been made, it has been rejected. This explains why "head in entry" is necessary -- since we can't have a "Feed of Feeds", we need an alternative mechanism for associating Feed metadata with entries that have been copied from other feeds. The primary arguments against "Feed of Feeds" have been (my apologies if I forgot some...) 1. Fear that an arbitrarily deep nesting of feeds might result in excessively large feeds. (i.e. Feed of Feeds of Feeds of Feeds...) 2. Belief that a need to handle nested feeds would increase complexity for client developers. With HeadInEntry, clients are not required to understand the sourcing issues, but have the necessary data available if they wish to use it. 3. Desire to simplify the migration path from RSS and Atom 0.3 to Atom V1.0. The introduction of "Feed of Feeds" would result in a drastic change in the structure of feeds that might require significant modifications to the design of existing clients and thus tend to retard efforts to move to the new format. While we should be completely open to such drastic structural changes, we should only accept such changes if the benefits of doing so are clear, compelling and overweigh the costs of migration. 4. Questions concerning attribution in interfaces. If an entry is extracted from a feed nested within another feed, then to which feed should the entry be associated in an interface? Or, should the interface attempt to show the full "path" of the nesting hierarchy that contains the entry? With "Head in Entry" it is likely that people will say that an entry "belongs" to whatever feed it was found in. However, with "Feed of Feeds" it is more likely that client developers and users will seek to associate the entry with its source feed. (Note: This is a psychological or social issue, not a technical one.) 5. Issues concerning partially nested feeds. For instance, one may wish to incorporate a single entry from a feed into another feed. If the approach is to simply nest the source feed, can a partial feed be nested? If so, what feed metadata should be maintained in the nested feed? 6. Concern that "Feed of Feeds" really doesn't buy you much that Head In Entry doesn't already provide in the normal case. One advantage provided by Feed of Feeds is that feed metadata would not be repeated in the case of multiple entries from a single feed being incorporated into another. However, this may not be the normal case. The requirement for "feed of feeds" is primarily driven by searching and matching engines and other entry aggregators that tend not to experience enough locality of reference in their results to have large numbers of results from a single feed. In this case, the occasional repetition of feed meta data in elements is probably acceptable. I may have forgotten some of the arguments, but this should provide a good refresher and/or catch-up on the basic issues... bob wyman From owner-atom-syntax@mail.imc.org Mon Jan 10 12:31: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 MAA07485 for ; Mon, 10 Jan 2005 12:31: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 j0AHHVFl010048; Mon, 10 Jan 2005 09:17: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 j0AHHVCf010047; Mon, 10 Jan 2005 09:17:31 -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 j0AHHV1q009992 for ; Mon, 10 Jan 2005 09:17: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 7E802B5 for ; Mon, 10 Jan 2005 09:17:23 -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 j0AHHIKB008469 for ; Mon, 10 Jan 2005 09:17:23 -0800 (PST) Date: Mon, 10 Jan 2005 09:33:09 -0800 From: Walter Underwood To: Atom WG Subject: Re: Hash for Links [Was: Re: Posted PaceEnclosuresAndPix] Message-ID: <7A478B12866CB46051FE2D66@diva.verity.com> In-Reply-To: <2bcdc7c405010818143d6ab41d@mail.gmail.com> References: <1f2ed5cd050105162514f7773f@mail.gmail.com> <1f2ed5cd050106050455c75c9d@mail.gmail.com> <2bcdc7c405010609374df235f3@mail.gmail.com> <41E01953.7030404@dehora.net> <41E03C53.1000701@franklinmint.fm> <2bcdc7c405010818143d6ab41d@mail.gmail.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0AHHV1q010040 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit This is really cache management. Use e-tags, from the HTTP 1.1 spec. Or use an HTTP cache, which would require no changes to Atom. Going thorugh a client-side HTTP 1.1 cache would automatically take advantage of the e-tags and other caching information in HTTP. wunder --On Saturday, January 08, 2005 06:14:50 PM -0800 James Snell wrote: > > I really don't want to be going down the road of requiring HTTP header > equivalents in the Atom feed, etc. All I want is the ability to > specify a hash of whatever it is that is being linked to. It could > work in both link and content elements and one could easily use the > Content-MD5 header to verify whether or not the resource referenced > has been modified since the time it was included in the Entry. > > The URI and the length of the file do not guarantee that the content > has not changed and yes, I had considered this as a possible non-core > extension but wanted to float it as a core item first. > > > On Sat, 08 Jan 2005 15:02:27 -0500, Robert Sayre wrote: >> >> Bill de hÓra wrote: >> >> > >> > >> >> > >> hash="{generated_hash_value}" >> >> hashalg="{uri_identifying_the_hash_algorithm_used" /> >> >> >> >> The hash and hashalg attributes would be optional but MUST appear >> >> together. >> >> >> >> Thoughts? (If we have more than two people respond favorably to this, >> >> I'll write up a Pace for it) >> > >> > >> > >> > Seems like a good idea - would it be possible to move them into elements? >> >> >> Well, Content-Length lives in the attributes as "length", but I don't >> think we need to make a home for every HTTP header. Content-MD5 will >> work just fine; it would probably be wise to send a HEAD request before >> automatically downloading a giant mp3. Furthermore, you'll get a good >> enough identifier by concatenating the URI and the length. Something >> more accurate will require a HEAD request. Thirdly, there's absolutely >> no reason to have this in core. >> >> Robert Sayre >> >> > > > -- > - James Snell > http://www.snellspace.com > jasnell@gmail.com > -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Mon Jan 10 13:21: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 NAA11116 for ; Mon, 10 Jan 2005 13:21: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 j0AIBiwD059812; Mon, 10 Jan 2005 10: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 j0AIBiIe059811; Mon, 10 Jan 2005 10:11:44 -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 j0AIBigQ059596 for ; Mon, 10 Jan 2005 10:11:44 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 30810 invoked by uid 17064); 10 Jan 2005 18:11:37 -0000 Received: from unknown (HELO [192.168.0.8]) ([193.251.47.207]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 10 Jan 2005 18:11:37 -0000 In-Reply-To: <41E1CC79.9070508@franklinmint.fm> References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <41DEF794.5050707@franklinmint.fm> <63C87CE6-629D-11D9-8C94-000A95D9FA7A@bblfish.net> <41E1CC79.9070508@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0E9AA37E-6333-11D9-8C94-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: atom-owl@googlegroups.com, "'Atom WG'" From: Henry Story Subject: Re: Atom Link element: Failure Date: Mon, 10 Jan 2005 19:11:32 +0100 To: Robert Sayre , Tim Bray X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ok, I give up on this task. I have just found that when there is a rdf:Resource you can't also have attributes. And that attributes have to be qualified. It is a real pity. It would be good to make a list of what we would have needed from RDF/XML to make Atom be rdf, and then work backwards to create RDF/XML2 where this works out fine. Henry On 10 Jan 2005, at 01:29, Robert Sayre wrote: > Henry Story wrote: > >> [snip] >> 4) Property attributes >> ---------------------- >> >> both hreflang, href and all the other properties of Link are unique, >> and given that they are string literals (subsets of them at least, >> but nevertheless) they can be move into attributes on Link >> >> >> > hreflang="de" >> href="http://example.org/de/2003/12/13/Atom03"/> >> > > > Use of unqualified attributes is deprecated in RDF/XML (check the > validator). My opinion is that the transformation you're looking for > would be easier with XSLT. You are right. The validator at is really useful. [snip] >>> >>> It gets a POST with a fairly average atom entry, but there are >>> extensions in funny places. Like most people, the server stores >>> standard fields in a relational database, so there are columns for >>> title, summary, etc. in a table called something like >>> "journal_entries". It would be fairly easy to store immediate >>> children of entry in an "unknown_xml" field, and pass them through, >>> but what about the other extensions? Using an RDF store might make >>> this problem a lot easier, but I don't forsee a mass migration in >>> that direction happening this year or next. >> >> >> You don't need a specialized RDF storage, though very good ones >> exist. There are schemes to map RDF into any relational database, >> just as there are schemes to map objects into relational databases. >> In fact most RDF storage tools in Java provide this. > > > That's not my point. My point is that there's a staggering amount of > data currently living in RDBMSes, and people aren't going to > re-architect their storage to use Atom. I was not trying to get people to use RDF databases at the back end. I was just hoping that a well engineered XML document would with a little care also turn out to be a well engineered RDF document. That would provide maximum flexibility in that it would allow people to move into the rdf world seamlessly. > Robert Sayre > From owner-atom-syntax@mail.imc.org Mon Jan 10 13:43: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 NAA12289 for ; Mon, 10 Jan 2005 13:43: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 j0AIY6dn076705; Mon, 10 Jan 2005 10:34: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 j0AIY6bl076704; Mon, 10 Jan 2005 10:34: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 j0AIY6eF076650 for ; Mon, 10 Jan 2005 10:34: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 (sccrmhc12) with SMTP id <2005011018340401200pis6oe>; Mon, 10 Jan 2005 18:34:04 +0000 Date: Mon, 10 Jan 2005 11:34:02 -0700 Subject: Re: PaceFeedRecursive 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: <9C395894-629F-11D9-B5EE-000D93324AD6@gbiv.com> Message-Id: <3374F506-6336-11D9-A37A-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, January 9, 2005, at 05:36 PM, Roy T. Fielding wrote: > I just created a starting point for a proposal on making the > feed element recursive, eliminating the need for RDF syntax, > atom:head, and a bunch of things proposed in other paces regarding > aggregators and digital signatures. > > http://www.intertwingly.net/wiki/pie/PaceFeedRecursive > Perhaps instead of making feed recursive, it would be better to have one more kind of document element to be used for aggregate feeds. For example: ... ... ... ... ... ... This would get rid of the problem of feeds of feeds of feeds..., but would raise a few questions: * Does need a and/or the kinds of things it contains>? I'd say yes, and it's role would be just like the feed/head in an aggregate feed based on PaceHeadInEntry. * If one aggregates s, does one need to carry forward data from aggregation/head, and if so, how does one do that? I'd be willing to punt on this and say that it just can't be done. Allowing it would be similar to reintroducing feeds of feeds of feeds... On the question of eliminating atom:head, if we go this route, we could eliminate entry:head, but feed:head was created for reasons other than enabling it to be embedded in entries. The rationale for the pace states: > Simplifies description of the Atom syndication format to containers > (feed, entry, content) and metadata that targets its own parent (feed > or entry). > I've been mulling over the question of what the hierarchical placement of an element means, and came up with the following possibilities for what a child element might be: 1) metadata about its parent (eg. modification date of an entry). 2) metadata about its parent's content??? For example, does name the author of an entry, or of it's content? If we decide that metadata about the content itself must be an attribute in the content element itself, then we can eliminate this one. 3) the parent's content (eg. entries in a feed, content in an entry). 4) a container for other child elements just for convenience (eg. head in a feed)--which would mean that the container's children could be metadata about their grandparents, perhaps metadata about the grandparent's content, or the grandparent's content itself. Eliminating feed/head would eliminate this one. But remember that feed/head predates PaceHeadInEntry--it was created for a different purpose, so we may not want to be too quick to toss it out. That's a slightly different view than what you describe, but not a whole lot--assuming 2 and 4 are gone, elements are either metadata about their parent, or their parent's content. Without understanding the format, one can't tell which a particular element is unless we did something like the following (which I am NOT advocating--I'm happy with applications having to know a little about the format if they care to distinguish): ... ... ... ... If we explicitly state that extension elements may only interact with other elements in their own namespace and with their immediate parents (ie. they may be metadata about or the content of their immediate parents, or may interact as defined in the extension with other elements from the extension), we eliminate problems with extension elements trying to influence the interpretation or handling of their siblings, and eliminate questions of inheritance from feed to entry (except with elements defined in the Atom core, a la ). From owner-atom-syntax@mail.imc.org Mon Jan 10 13:51: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 NAA12724 for ; Mon, 10 Jan 2005 13:51: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 j0AIhuYR085008; Mon, 10 Jan 2005 10:43: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 j0AIhu6R085005; Mon, 10 Jan 2005 10:43:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from priv-edtnes57.telusplanet.net (outbound01.telus.net [199.185.220.220]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0AIhtww084921 for ; Mon, 10 Jan 2005 10:43:55 -0800 (PST) (envelope-from jeremy@jeremygray.ca) Received: from dora9 ([207.6.230.92]) by priv-edtnes57.telusplanet.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050110184353.QXEV3277.priv-edtnes57.telusplanet.net@dora9>; Mon, 10 Jan 2005 11:43:53 -0700 Reply-To: From: "Jeremy Gray" To: "'Henry Story'" Cc: , "'Atom WG'" Subject: RE: Atom Link element: Failure Date: Mon, 10 Jan 2005 10:43:56 -0800 Message-ID: <000c01c4f744$58a34b70$6400a8c0@dora9> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <0E9AA37E-6333-11D9-8C94-000A95D9FA7A@bblfish.net> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0AIhtww084998 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Henry, would you mind sending me a copy of the example you were trying to work up? I took a scroll through your recent emails to see if I could figure out which one gave you so much trouble, but I'm not sure if I'm looking at the right materials or not. I'm curious because you mention that when there is an "rdf:Resource[sic] you can't also have attributes" which, given that rdf:resource applies only to property elements, makes sense. As such, I'm wondering what exactly you were trying to accomplish when you hit your roadblock. Thanks in advance, Jeremy -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Henry Story Sent: Monday, January 10, 2005 10:12 AM To: Robert Sayre; Tim Bray Cc: atom-owl@googlegroups.com; 'Atom WG' Subject: Re: Atom Link element: Failure Ok, I give up on this task. I have just found that when there is a rdf:Resource you can't also have attributes. And that attributes have to be qualified. It is a real pity. It would be good to make a list of what we would have needed from RDF/XML to make Atom be rdf, and then work backwards to create RDF/XML2 where this works out fine. Henry On 10 Jan 2005, at 01:29, Robert Sayre wrote: > Henry Story wrote: > >> [snip] >> 4) Property attributes >> ---------------------- >> >> both hreflang, href and all the other properties of Link are unique, >> and given that they are string literals (subsets of them at least, >> but nevertheless) they can be move into attributes on Link >> >> >> > hreflang="de" >> href="http://example.org/de/2003/12/13/Atom03"/> >> > > > Use of unqualified attributes is deprecated in RDF/XML (check the > validator). My opinion is that the transformation you're looking for > would be easier with XSLT. You are right. The validator at is really useful. [snip] >>> >>> It gets a POST with a fairly average atom entry, but there are >>> extensions in funny places. Like most people, the server stores >>> standard fields in a relational database, so there are columns for >>> title, summary, etc. in a table called something like >>> "journal_entries". It would be fairly easy to store immediate >>> children of entry in an "unknown_xml" field, and pass them through, >>> but what about the other extensions? Using an RDF store might make >>> this problem a lot easier, but I don't forsee a mass migration in >>> that direction happening this year or next. >> >> >> You don't need a specialized RDF storage, though very good ones >> exist. There are schemes to map RDF into any relational database, >> just as there are schemes to map objects into relational databases. >> In fact most RDF storage tools in Java provide this. > > > That's not my point. My point is that there's a staggering amount of > data currently living in RDBMSes, and people aren't going to > re-architect their storage to use Atom. I was not trying to get people to use RDF databases at the back end. I was just hoping that a well engineered XML document would with a little care also turn out to be a well engineered RDF document. That would provide maximum flexibility in that it would allow people to move into the rdf world seamlessly. > Robert Sayre > From owner-atom-syntax@mail.imc.org Mon Jan 10 14:25: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 OAA15068 for ; Mon, 10 Jan 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 j0AJD5d1008913; Mon, 10 Jan 2005 11:13: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 j0AJD5bj008912; Mon, 10 Jan 2005 11:13:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cmailg2.svr.pol.co.uk (cmailg2.svr.pol.co.uk [195.92.195.172]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0AJD4LL008791 for ; Mon, 10 Jan 2005 11:13:04 -0800 (PST) (envelope-from lists@isofarro.uklinux.net) Received: from user-6184.lns1-c8.dsl.pol.co.uk ([84.66.184.40] helo=[192.168.0.2]) by cmailg2.svr.pol.co.uk with esmtp (Exim 4.14) id 1Co4yC-0005I7-Af; Mon, 10 Jan 2005 19:12:52 +0000 Message-ID: <41E2D38E.6010003@isofarro.uklinux.net> Date: Mon, 10 Jan 2005 19:12:14 +0000 From: Isofarro User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'Atom WG'" CC: bobwyman@pubsub.com, "'Roy T. Fielding'" Subject: Re: PaceFeedRecursive References: <20050110164940.D0F947247A9@mail.pubsub.com> In-Reply-To: <20050110164940.D0F947247A9@mail.pubsub.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: > Roy T. Fielding wrote: > >>a proposal on making the feed element recursive (Speaking for myself, I'm not clued-up enough to understand the problem / use-case Roy's pace solves) > Equivalent proposals have often been made in the past (sometimes by > me!). These proposals fall in the category that we've come to know as "Feed > of Feeds". Agreed. I'm still none the wiser as to alternatives of handling Feed of Feed type scenarios. Using an entry element to describe a feed inside a feels rather hackish. Using an OPML/OML document feels like using two distinct vocabularies where one should do. My intention is to create an Atom-enabled "space" that is navigatable. Resources are Atom Entries, Collections of resources are Atom Feeds. From a starting point of an Atom Entry, I would like to be able to follow a series of links to find other related or neighbourly Atom entries - something like going to the parent feed and find a sibling feed. I find Roy's pace useful for what I want to do - have a way of expressing a collection of collections - feeds of feeds. For my purposes I can definitely live with one level of recursion or nesting: ... ... ... I can also live with the internal feed not having any entry elements - it will just be a pointer and metadata to another feed (presumably via a link element). From my perspective there was a related/relevant discussion going on in the Atom Protocol mailing list a few months ago about Collections and Resources. Its easy enough to see a collection as an Atom feed, and a Resource as an Atom entry, but I can't get my head around the correct way of representing a Collection of collections without looking at either a feed inside a feed, or an OPML/OML representation for each Collection of Collections hierachy I'm expecting. If we are going to use feeds and entries to represent collections and resources, we should at least be able to express collections of collections with the same vocabulary. > The primary arguments against "Feed of Feeds" have been (my > apologies if I forgot some...) > 1. Fear that an arbitrarily deep nesting of feeds might result in > excessively large feeds. (i.e. Feed of Feeds of Feeds of Feeds...) Limit the nesting to one level. (Feed inside a feed). > 2. Belief that a need to handle nested feeds would increase > complexity for client developers. With HeadInEntry, clients are not required > to understand the sourcing issues, but have the necessary data available if > they wish to use it. With the above limitation the complexity would be identical to handling an entry, except the link element definitively refers to an Atom Feed rather than an Atom Entry. > 3. Desire to simplify the migration path from RSS and Atom 0.3 to > Atom V1.0. The introduction of "Feed of Feeds" would result in a drastic > change in the structure of feeds that might require significant > modifications to the design of existing clients and thus tend to retard > efforts to move to the new format. The additional work required is to handle a feed element at the same point as expecting an entry element. The metadata expected in the feed is roughly the same as a summary-only without the summary. > 4. Questions concerning attribution in interfaces. If an entry is > extracted from a feed nested within another feed, then to which feed should > the entry be associated in an interface? The limitation above I guess disallows this particular situation. > 5. Issues concerning partially nested feeds. For instance, one may > wish to incorporate a single entry from a feed into another feed. Same as 4.) > 6. Concern that "Feed of Feeds" really doesn't buy you much that > Head In Entry doesn't already provide in the normal case. Just the ability to list feeds that are "filters" of the current feed. Taking del.icio.us as an example, the collection at http://del.icio.us/tag/css would give me recent links with the css tag. I'd like to have the ability to refer to the collection http://del.icio.us/tag/css+tutorial within that feed since it is a related feed - a more refined filter than the current feed. I'd also like to be able to link the other way - in the /tag/css+tutorial collection be able to refer to the "parent" collection /tag/css and /tag/tutorial. For me this would be a nice to have. I don't demand it. (Although recommendations of alternative approaches would be very welcome) Just my ha'penny. Mike (P.S. Does Roy Fielding's email domain name - gbiv.com have anything to do with the colours of the Rainbow, as in roygbiv [Red Orange Yellow Green Blue Indigo Violet])? From owner-atom-syntax@mail.imc.org Mon Jan 10 15:10: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 PAA19038 for ; Mon, 10 Jan 2005 15:10: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 j0AJxYhG048203; Mon, 10 Jan 2005 11:59: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 j0AJxYFF048202; Mon, 10 Jan 2005 11:59: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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0AJxXPY048150 for ; Mon, 10 Jan 2005 11:59:34 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so66257rnz for ; Mon, 10 Jan 2005 11:59: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=LeCC9IbNE/ike4/obASnO4k1owaHMQKTN6+lteIjY4RZOK8hgE6eEwbOxpr3YcoQPX6rxiFWyJEnAcFR1NApL1X/AVb0oD2O6OwJHMI5a7XZXReBfZ2J2+p8PalDFrHAIgGQl9xriTJ9dACMe7G9PJvUx5iCnPJNFRqeNvYdviU= Received: by 10.38.8.48 with SMTP id 48mr228381rnh; Mon, 10 Jan 2005 11:59:37 -0800 (PST) Received: by 10.38.179.71 with HTTP; Mon, 10 Jan 2005 11:59:37 -0800 (PST) Message-ID: <1f2ed5cd0501101159dcab0bf@mail.gmail.com> Date: Mon, 10 Jan 2005 20:59:37 +0100 From: Danny Ayers Reply-To: Danny Ayers To: bobwyman@pubsub.com Subject: Re: PaceFeedRecursive Cc: "Roy T. Fielding" , Atom WG In-Reply-To: <20050110164940.D0F947247A9@mail.pubsub.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <9C395894-629F-11D9-B5EE-000D93324AD6@gbiv.com> <20050110164940.D0F947247A9@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 10 Jan 2005 11:49:35 -0500, Bob Wyman wrote: > > Roy T. Fielding wrote: > > a proposal on making the feed element recursive > The primary arguments against "Feed of Feeds" have been (my > apologies if I forgot some...) Thanks Bob. IMHO there are pretty strong counter-arguments to 1-5, but this is trickier: > 6. Concern that "Feed of Feeds" really doesn't buy you much that > Head In Entry doesn't already provide in the normal case. Ok, I don't think there is any benefit in the normal case (feed ::= meta, (meta, content)*), but the recursive nesting method makes it possible to convey information about relationships between feeds. Which begs the questions: How useful are the semantics of one feed containing another? How desirable is it to convey such information in Atom format? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Mon Jan 10 15:25: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 PAA20756 for ; Mon, 10 Jan 2005 15:25: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 j0AKHaCw066035; Mon, 10 Jan 2005 12:17: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 j0AKHaU2066021; Mon, 10 Jan 2005 12:17: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 j0AKHYtA065851 for ; Mon, 10 Jan 2005 12:17: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 1Co5yO-0001jd-T9; Mon, 10 Jan 2005 20:17:09 +0000 Message-ID: <41E2E2D9.4090309@franklinmint.fm> Date: Mon, 10 Jan 2005 15:17:29 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: bobwyman@pubsub.com, "Roy T. Fielding" , Atom WG Subject: Re: PaceFeedRecursive References: <9C395894-629F-11D9-B5EE-000D93324AD6@gbiv.com> <20050110164940.D0F947247A9@mail.pubsub.com> <1f2ed5cd0501101159dcab0bf@mail.gmail.com> In-Reply-To: <1f2ed5cd0501101159dcab0bf@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 Danny Ayers wrote: >On Mon, 10 Jan 2005 11:49:35 -0500, Bob Wyman wrote: > > >> 6. Concern that "Feed of Feeds" really doesn't buy you much that >>Head In Entry doesn't already provide in the normal case. >> >> > >Ok, I don't think there is any benefit in the normal case (feed ::= >meta, (meta, content)*), > It won't screw up DSig as badly. "Collectable Signatures"[0] will still require XPath, though. Robert Sayre [0] http://cvs.apache.org/viewcvs.cgi/xml-security/src_samples/org/apache/xml/security/samples/signature/CreateCollectableSignature.java?rev=1.9&view=markup From owner-atom-syntax@mail.imc.org Mon Jan 10 16:50: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 QAA05830 for ; Mon, 10 Jan 2005 16:50: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 j0ALbgcK040411; Mon, 10 Jan 2005 13: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 j0ALbge1040410; Mon, 10 Jan 2005 13:37:42 -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 j0ALbfOn040356 for ; Mon, 10 Jan 2005 13:37:42 -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 j0ALXRsV013199 for ; Mon, 10 Jan 2005 16:37:39 -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 CHX73621 (AUTH bob@wyman.us); Mon, 10 Jan 2005 16:24:44 -0500 (EST) Message-Id: <200501102124.CHX73621@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Atom Syntax'" Subject: RE: Please Review: Dissemination of Earthquake / Tsunami data via Atom Date: Mon, 10 Jan 2005 16:24:34 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01C4F730.E41DDDF0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcT13GROkNSRvIJ/S228s/ELbbcWDABfJB8Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <20050108234548.528DE99DC@mailrelay.t-mobile.com> 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_003F_01C4F730.E41DDDF0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit We've made a good bit of progress on cleaning up our PubSub Earthquake/Tsunami reporting service and would like to ask folk on the list to take a look at the feed we're generating. (Note: This isn't "publicly" announced yet, so please restrict comments to personal email or the list.) You can see a sample Atom feed of all recent earthquakes (and tsunami reports in "AddOn" fields - when we receive them) at: http://atom.pubsub.com/90/69/6169a3b8e062b66f7afd592f.xml Use "View Source" to see the actual Atom file if you are using a browser that supports style-sheets. I'm sure there is much to be said about this kind of service; however, my interest in sending this message to this group is to get comments on our use of Atom for this application. Please note that in the near future we'll be allowing people to access this data via "Atom over XMPP PubSub" for real-time push distribution. Thus, you'll be able to say things like: "Only send me quakes over 5.0 magnitude that occur in Southern California and have 'waveforms' data in AddOn records." We're also going to be supporting a pure TCP/IP "telnet" socket connection for folk who want the full stream. Naturally, REST, SOAP, Email, and other distribution mechanisms will either be enabled by default (as with all other PubSub services) or could be provided if demand exists. I am particularly interested in "Atom-related" comments at this point. For instance, you'll notice "Delete" messages in the feed. We've talked about "Delete" or "Retract" capability often in the past and I've usually argued against it. However, it turns out to be necessary with this kind of feed since often earthquake reports are retracted as erroneous - often as the result of telemetry glitches. How should we best handle the need for "Delete" in this context? What will be easiest for clients to handle? Also, please be aware that I am aware of no existing standards for this data. If you know of any such standards, please let me know. (Note: I am aware of CAP and have participated in that forum. It solves a different problem.) Thanks in advance for your assistance. My hope is that we'll be able to use Atom to make a real contribution to making the world just a bit safer. bob wyman ------=_NextPart_000_003F_01C4F730.E41DDDF0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

We’ve made a good bit of = progress on cleaning up our PubSub Earthquake/Tsunami reporting service and would = like to ask folk on the list to take a look at the feed we’re generating. = (Note: This isn’t “publicly” announced yet, so please = restrict comments to personal email or the list.)

 

You can see a sample Atom feed of = all recent earthquakes (and tsunami reports in “AddOn” fields = – when we receive them) at:

 

http:/= /atom.pubsub.com/90/69/6169a3b8e062b66f7afd592f.xml=

 

Use “View Source” to = see the actual Atom file if you are using a browser that supports = style-sheets.

 

I’m sure there is much to be = said about this kind of service; however, my interest in sending this message = to this group is to get comments on our use of Atom for this application. = Please note that in the near future we’ll be allowing people to access = this data via “Atom over XMPP PubSub” for real-time push distribution. = Thus, you’ll be able to say things like: “Only send me quakes over = 5.0 magnitude that occur in Southern = California and have ‘waveforms’ data in AddOn records.” = We’re also going to be supporting a pure TCP/IP “telnet” socket = connection for folk who want the full stream. Naturally, REST, SOAP, Email, and other distribution mechanisms will either be enabled by default (as with all = other PubSub services) or could be provided if demand exists. =

 

I am particularly interested in = “Atom-related” comments at this point. For instance, you’ll notice = “Delete” messages in the feed. We’ve talked about “Delete” or = “Retract” capability often in the past and I’ve usually argued against it. = However, it turns out to be necessary with this kind of feed since often = earthquake reports are retracted as erroneous – often as the result of = telemetry glitches. How should we best handle the need for “Delete” in = this context? What will be easiest for clients to = handle?

 

Also, please be aware that I am = aware of no existing standards for this data. If you know of any such standards, = please let me know. (Note: I am aware of CAP and have participated in that = forum. It solves a different problem.)

 

Thanks in advance for your = assistance. My hope is that we’ll be able to use Atom to make a real contribution = to making the world just a bit safer…

 

      =             &= nbsp;     bob wyman

 

------=_NextPart_000_003F_01C4F730.E41DDDF0-- From owner-atom-syntax@mail.imc.org Mon Jan 10 16:50: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 QAA05919 for ; Mon, 10 Jan 2005 16:50: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 j0ALd5wX041055; Mon, 10 Jan 2005 13:39: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 j0ALd55c041054; Mon, 10 Jan 2005 13:39:05 -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 j0ALd4Om041013 for ; Mon, 10 Jan 2005 13:39:04 -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 <20050110213902.OLAA17071.fed1rmmtao06.cox.net@[192.168.0.100]>; Mon, 10 Jan 2005 16:39:02 -0500 In-Reply-To: <822CE8FF-6317-11D9-B651-000A95DC3D90@mac.com> References: <9C395894-629F-11D9-B5EE-000D93324AD6@gbiv.com> <47FF7A4B-62A8-11D9-B651-000A95DC3D90@mac.com> <9D5C34FE-62BD-11D9-B5EE-000D93324AD6@gbiv.com> <822CE8FF-6317-11D9-B651-000A95DC3D90@mac.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0B3F680B-6350-11D9-AD98-000D93324AD6@gbiv.com> Content-Transfer-Encoding: 7bit Cc: Atom WG From: "Roy T. Fielding" Subject: Re: PaceFeedRecursive Date: Mon, 10 Jan 2005 13:39:02 -0800 To: Graham X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 10, 2005, at 6:54 AM, Graham wrote: > Seriously, though, all you've done is not bothered to flatten the > data at any point. Why is that a goal? We know all of the data is in the leaves, so "flattening" them is what happens when the entries are processed depth-first. > While this may please you, all it means is the software at the far end > has to wade through a few more sets of angle brackets and implement a > couple of stacks. Actually, a few less angle brackets (count them), and any client that tries to process XML without some awareness of hierarchy is not my concern. Design for the clients that matter. > Don't think for a second that your format contains more data that > the current flat format, I would hope not -- the point was to make that data available such that it would not have to be replicated in every entry. > because since it's all implicit, it's worthless. Implicit? Did you mean inherited? Hierarchical containment is explicit in XML. > If say, entries appear in two separate groups in a feed, it might > mean that they came from separate sources, or it might nor it might > not mean anything. Why not just make it explicit? You are not talking about my proposal, or at least it was fundamentally misunderstood. Wait until it gets filled-out. ....Roy From owner-atom-syntax@mail.imc.org Mon Jan 10 16:51: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 QAA06047 for ; Mon, 10 Jan 2005 16:51: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 j0ALjqJp050540; Mon, 10 Jan 2005 13:45: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 j0ALjqcC050539; Mon, 10 Jan 2005 13:45:52 -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 j0ALjqGN050533 for ; Mon, 10 Jan 2005 13:45:52 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 59764 invoked by uid 17064); 10 Jan 2005 21:45:56 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.251.47.242]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 10 Jan 2005 21:45:56 -0000 In-Reply-To: <0E9AA37E-6333-11D9-8C94-000A95D9FA7A@bblfish.net> References: <01F52E0B-60BC-11D9-8C94-000A95D9FA7A@bblfish.net> <41DEF794.5050707@franklinmint.fm> <63C87CE6-629D-11D9-8C94-000A95D9FA7A@bblfish.net> <41E1CC79.9070508@franklinmint.fm> <0E9AA37E-6333-11D9-8C94-000A95D9FA7A@bblfish.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/mixed; boundary=Apple-Mail-6-384816202 Message-Id: Cc: atom-owl@googlegroups.com, Robert Sayre , Tim Bray , jeremy@jeremygray.ca From: Henry Story Subject: Re: Atom Link element: Success Date: Mon, 10 Jan 2005 22:45:51 +0100 To: "'Atom WG'" X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-6-384816202 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Ok, I don't know what happened to me there. I must have been overly tired. I went to do some weigh lifting, came back and found that my reasoning is in fact correct. In fact if you put in the following rdf in the validator you get the following graph: --Apple-Mail-6-384816202 Content-Type: image/gif; x-unix-mode=0666; name="servlet_77206.gif" Content-Disposition: inline; filename=servlet_77206.gif Content-Transfer-Encoding: base64 R0lGODlhKQM8AaIAAP///wAAAP///gAA/wBjAP8AAAAAAAAAACH5BAEAAAIALAAAAAApAzwBAAP/ CLrc/jDKSau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqPyKRyyWw6n9CodEqt Wq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr9vv+Lx+z+/7/4CBgoOEhYaHiImKi4yNjo+QkZKT lJWWl5iZmpucnZ6foKGio6SlpqeoqaowCIGgy+0Po5y02ouz3rz7D4biSJbmiabqyrbuuyGhy80I utz+MMpJq7046827/2AojmRpnmiqrmzrvg0Sqgi63IyhiqDL7Q+jnLTai7PevPsPhuJIluaJpurK tm6LhCLocrujUARdbn8Y5aTVXpz15t1/MBRH/7I0TzRVV7Z1USQUQZfbv6FQBF1ufxjlpNVenPXm 3X8wFEeyNE80VVe2dUckAkGX2x8uFIGgy+0Po5y02ouz3rz7D4biSJbmiabqyrbuh0Qg6HL7w4ci EHS5/WGUk1Z7cdabd//BUBzJ0jzRVF3Z1uWQQNDl9odRoUDQ5faHUU5a7cVZb979B0NxJEvzRFN1 ZVs3QyIQdLn9YWQoAkGX2x9GOWm1F2e9efcfDMWRLM0TTdWVbV0LCQRdbn8YIQoEXW5/GOWk1V6c 9ebdfzAUR7I0TzRVV7Z1JyQCQZfbH0aJIhB0uf1hlJNWe3HWm3f/wVAcydI80VRd2daFkAgEXf9u fxilQhEIutz+MMpJq7046827/2AojmRpnmiqrmzrOkgEgi63P4ySoQgEXW5/GOWk1V6c9ebdfzAU R7I0TzRVV7Z1GyQQdLn9YZQOBYIutz+MctJqL8568+4/GIojWZonmqor27oMEgi63P4wSogCQZfb H0Y5abUXZ7159x8MxZEszRNN1ZVtXQWJQNDl9odRQhSBoMvtD6OctNqLs968+w+G4kiW5omm6sq2 LoAEgi63P4xSokDQ5faHUU5a7cVZb979B0NxJEvzRFN1ZVsXCQRdbn8Y5QQoEHS5/WGUk1Z7cdab d//BUBzJ0jzRVF3ZtkUCQZfbH0Y5AQoEXW7/fxjlpNVenPXm3X8wFEeyNE80VVe2ZZEIBF1ufxjl BCgCQZfbH0Y5abUXZ7159x8MxZEszRNN1ZVtVyQQdLn9YZRzoUDQ5faHUU5a7cVZb979B0NxJEvz RFN1ZdsVCQRdbn8Y5VwoEHS5/WGUk1Z7cdabd//BUBzJ0jzRVF3ZdkUCQZfbH0Y5FwoEXW5/GOWk 1V6c9ebdfzAUR7I0TzRVV7ZdkUDQ5faHUc6FAkGX2x9GOWm1F2e9efcfDMWRLM0TTdWVbVUkAkGX 2x9GOReKQNDl9odRTlrtxVlv3v0HQ3EkS/NEU3VlWxUJBF1ufxjlXCgQdLn9YZSTVntx1pt3///B UBzJ0jzRVF3ZdkUCQZfbH0Y5FwoEXW5/GOWk1V6c9ebdfzAUR7I0TzRVV7ZdkUDQ5faHUc6FAkGX 2x9GOWm1F2e9efcfDMWRLM0TTdWVbVckEHS5/WGUc6FA0OX2h1FOWu3FWW/e/QdDcSRL80RTdWXb FCENBF1ufxjlBCgCQZfbH0Y5abUXZ7159x8MxZEszRNN1ZVtSYRUAQADQZfbH0Y5AQoEXW5/GOWk 1V6c9ebdfzAUR7I0TzRVV7YNEVJC0NVA0OX2h1FOgEgJQZfbH0Y5abUXZ7159x8MxZEszRNN1ZVt M4RUEXR5A0GX2x9GKVEAACDpEoIutz+Mcv/Sai/OevPuPxiKI1maJ5qqK9syCOki6HIvRiDocvvD KCGKQNBlQNJF0OX2h1FOWu3FWW/e/QdDcSRL80RTdWVNhFQRdLmdUSDocvvDKCEKBF3uRVJF0OX2 h1FOWu3FWW/e/QdDcSRL80RTdWU5hFQRdLn9FwoEXW5/GKVDgaDL7YtIFUGX2x9GOWm1F2e9efcf DMWRLM0TTdWVnRBSQtDl9ocoAkGX2x9GyVAEgi63P0CkhKDL7Q+jnLTai7PevPsPhuJIluaJpurK LggpIehy+8OGIhB0uf1hlApFIOhy+ztESgi63P4wykmrvTjrzbv/YCiOZGmeaKquJ0JKCLr/3P4w AhSBoMvtD6NEEQi63P5wIVJC0OX2h1FOWu3FWW/e/QdDcSRL80RTdf0QUkLQ5faH8aFA0OX2hxGi QNDl9ocRkRKCLrc/jHLSai/OevPuPxiKI1maJ5qqa4WQLoIutz+MUqEIBF1ufxgZikDQ5faHsSFS RdDl9odRTlrtxVlv3v0HQ3EkS/NEU3VVENJF0OX2h1FKFAi63P4wKhQIutz+MEqFSBVBl9sfRjlp tRdnvXn3HwzFkSzNE01VEiElBF1ufxjldCgCQZfbHz4UgaDL7Q+jhIh0EXS5/WGUk1Z7cdabd//B UBzJ0jzRVN0QUgRdbn8Y5aQoAkGX2x8u/xSBoMvtD6OcDZESgi63P4xy0movznrz7j8YiiNZmiea qhNCSgi63P4wykkbCkXQ5fZvKBRBl9sfRjknIiUEXW5/GOWk1V6c9ebdfzAUR7I0TzRVGYQUQZfb H0Y5KUWhCLrc7igUQZfbH0Y5qUOkhKDL7Q+jnLTai7PevPsPhuJIluaJpidCiqDL7Q+jnLQyFKoI utyMoYqgy+0Po5yUIlJC0OX2h1FOWu3FWW/e/QdDcSRL80RTECFF0OX2h1FOWikKXW5G0OX2h1FO WiEiJQRdbn8Y5aTVXpz15t1/MBRHsjRPNMUQUkLQ5faHUU5arUSBoMvtD6OctNqHSBF0uf/9YZST Vntx1pt3/8FQHMnSPNE0QkgJQZfbH0Y5abUXZ715Z4gUQZfbH0Y5abUXZ7159x8MxZEszRNNFYSU EHS5/WGUk1Z7cdab94lIEXS5/WGUk1Z7cdabd//BUBzJ0jzREiFF0OX2h1FOWu3FWW/eNSJF0OX2 h1FOWu3FWW/e/QdDcSRL80Q/hBRBl9sfRjlptRdnvXn3CiFF0OX2h1FOWu3FWW/e/QdDcSRL80Qz hBRBl9sfRjlptRdnvXn3ECElBF1ufxjlpNVenPXm3X8wFEeyNE90QogQdLn9YZSTVntx1pt3fxFS BF1ufxjlpNVenPXm3X8wFEeyNE+0QUj/EXS5/WGUk1Z7cdabd88RUkLQ5faHUU5a7cVZb979B0Nx JEvzNBFSBF1ufxjlpNVenPXm3X8GIUXQ5faHUU5a7cVZb979B0NxJEvzDBEiBF1ufxjlpNVenPXm 3X8JIULQ5faHUU5a7cVZb979B0NxJEvz5BBSBF1ufxjlpNVenPXm3X8LIULQ5faHUU5a7cVZb979 B0NxJEvzvBBSBF1ufxjlpNVenPXm3f8NIUXQ5faHUU5a7cVZb979B0NxJEvzlBAiBF1ufxjlpNVe nPXm3X8QQIgQdLn9YZSTVntx1pt3/8FQHMnSPBuEFEGX2x9GOWm1F2e9efcfbBAiBF1u/38Y5aTV Xpz15t1/MBRHsjRPACFC0OX2h1FOWu3FWW/e/QclhAhBl9sfRjlptRdnvXn3HwzFkSxNEiFC0OX2 h1FOWu3FWW/e/QcthAhBl9sfRjlptRdnvXn3HwzFkSxNECFC0OX2h1FOWu3FWW/e/Qc1hBB0uf1h lJNWe3HWm3f/wVAcydLsECIEXW5/GOWk1V6c9ebdf7BDiBB0uf1hlJNWe3HWm3f/wVAcydLUEELQ 5faHUU5a7cVZb979B0OECEGX2x9GOWm1F2e9efcfDMWRLE0LIULQ5faHUU5a7cVZb979B8MFIQRd bn8Y5aTVXpz15t1/MBRHsjQphBB0uf/9YZSTVntx1pt3/8HQQYgQdLn9YZSTVntx1pt3/8FQHMnS jBBC0OX2h1FOWu3FWW/e/QfDCCEEXW5/GOWk1V6c9ebdfzAUR7I0HYQIQZfbH0Y5abUXZ7159x8M J4QQdLn9YZSTVntx1pt3/8FQHMnSZBBC0OX2h1FOWu3FWW/e/QdDCyFC0OX2h1FOWu3FWW/e/QdD cSRLE0AIQZfbH0Y5abUXZ7159x8MM4QQdLn9YZSTVntx1pt3/8FQHMmyRAhBl9sfRjlptRdnvXn3 Hww3hBB0uf1hlJNWe3HWm3f/wVAcyZJECEGX2x9GOWm1F2e9efcfDDmEEHS5/WGUk1b/e3HWm3f/ wVAcyVJECEGX2x9GOWm1F2e9efcfDD2EEHS5/WGUk1Z7cdabd//BUBzJEkQIQZfbH0Y5abUXZ715 9x8MQYQQdLn9YZSTVntx1pt3/8FQHMnyQwhBlxuwCkGX2x8CVIWgWoWgy+0Po5wRVSHocvs3VIWg y81YhaDL7d9QFQBoIdDl9odRTogKCkGX298hQtDlZqxC0OX2hwBVIahW7a611lKoFEGX2/+hKgRd bv+GqgCgEAoACqsQVKt2F0BVCLrc/jDKSau9OOvNu4cIIehyK1Yh6FatoioEXW4HVIWgWoWgy+0P ASotBF1uf4eqAEARFKoKCwCqsAoA/wqrCkG3SrG0AABLC0G3SrG0AABLC0GXu7EKQAGrEHS5/RWq QtDl9ocNFRQAYBWCLre/QoSgy71YhaBbtYqqEHS5HVAVgmrV7lprrYWqEHS5/R+qQtDdKgRdbgdU BQCFUAAAWIWgWrW7AKpC0OX2h1FOWu3FWW/e/UMIQZd7sQpBt2oVVSHo8hYWgm7VKqpC0OX2hwBV ASiCLrc/Q1UAoIVAq7SwoAoAq0ABsAoAAKsAFBCqoAoBqlSxCkABoQqqEKAKQZebsQpAEXS5/Ruq QtDl9ocMlSqAIuhy+y9ECLrcilUIulWrqApBl7ewEHSrVlEVgi63M6pC0OX2d6gKQf+XqxB0uR2r AEC1INAqBF1uxSoEXW5/GOWk1V6c9ebdP4QQdLkXSxVgFQFgqQKsItCqKgTVqlVUBaCAUAVVCFAF hQVQhaCrVQhQpQqoCkF3q7AKAEsVALAUCgABqgCwoAoAoQqgsKAKAKtAAbAKAACrABQQqqAKAapU sQpAAaEKqhCgSlUVKlUAwFIFUARd1sKqAigsgCrAUgVYRaBVVQhQpYWFoKtYqgCApQUAWKqwigBV WliApQoAWFoIukrMjAFUqgCrCABLFWAVgVZVIahWraIqANVCAFVaWIClCgAIVQi6DIVVBYClCgBY CgWAAFUACFVVgIClCgBYWgCKUIX/oFq1WKoAgFUAAFgKAKoFAVRpYSHocvvDKCet9uKsN+9eIYSg y81YBaCAUIWgWrWAqgAUEKAKQbVqFVUBgCJAFRQWQBVgFYAi6GoVAlRpYVUh6G4VAlRBYQFUAVYB KCBAFYJq1WIVgAJWAShgFYACAlQBIFRBFRaCatViFYIuVCGoVgGWLiggVEEVAlRBYVUBAJYuKCBU QRUCVEFhAVQBQhWCrlYhVAEUFmDpggJCFVQhQJUCFhQAYBUAAFYBKGAVgAJWASiCrhIzY6gKQAGh CkG1agFVASggQBWCatUqqgIARYAqKCyAKsAqAAUEqELQ5SoEqILCAqgCrAJQQIAq/wRdqEKAKlWs AlDA0gUArEJQLSgEhapVVAUAigBVUFhQhaDL7Q+jnLTai7PevHuFEIIud2MVgAJCFYJq1QKqAlAE 3a1CUK1aQFUAClgFoIBVAIqgq1UIUKUKqApBV6sQoAoKC0G1SrEKQBF0qxZQqQKsIgAsVQBFUKgq hCoAwFIAUATdqkJQqCoEwNIFRVCtUqwCUEAAwNIFUASFKsUqUACsAlAEVSxVgC0EgKULCghVAIWF oIqlCqAIClWKVaAAWAWqiqC7xMwWqgJQQKhCUK1aQFUAiqC7VQiqVQuoCkABqwAUsApBF6oQdLkK AaqgsBBUqxSrABRBFUsVQBEUqv8Uq0BVEaBKFVCpAgBWIahWLVYBKGBpIehy+8MoJ6324qw3734h hKDL3VgFoIBQhaBatYCqABRBd6sQVKsWUOnCLgKWLoKuYukiqFbtKlQFoIBVCLpVhQUAVQi6VbsA VSGoVq2iKgAFBIAqQKgCKCwE1apVVIWgWrW7FKpCUK1SrAJQBF3mwgKoAoQqqEKAKi0sAIDCAqgC hKoqBN2tQoAqVawCANWCAKpUsQpAAasAFLAKQZeXEHS5CwugChCqEFSrFlAVgCLobhWCatUCqgJQ wCoABaxC0IUqBF2uQoAqKCwE3arCAoAqBIUqxSoABQSAKkCogioEqNLCQlDFUgX/AKxCUK1arAJQ wNJC0OX2h1FOWu3FWW/evUIIQZfbsQpAAaEKqhCgCgoLsFQBAKEKALAKQbVqFZUu7CJg6QIAVgGA qkJQBVBYAFCFoFVaWFCFoFq1iqoQdKEKQau0sKAKAKtAAbAKFEG1SrEKFEG1ahVVIahW7a6FqhBU qxSrABRBl6GwAKoAAUsVFBCqAAoLqqCwAKoAqwAUQVerEKAKCgugChCgoAABqqCwALBUYRUBqrSw EHSZmJlCVQAKCFVQhQBVUFiApQoACFUAgFUIqlWrqFQBFAGqoLAQdKEKQbVqsQpAAasQVKtWURWC apViFYACVoECYBUoAFaBIuhC/wEWAEBhIahWLVYBKGAVKIIutz+MctJqL8568+4RIehyO6AqAAUE qCpAAKgqBKhSVVRaAIqgWrWLCqAAEAqgAAEKoBC0qgpBS0sBlRYAYGkBAJYWgCLoVhUWQBWCKpYu wBYCrapC0KoqBKhSVVRaALsIqhBUsXRhF0FXqxB0sVQBFEGXtbCqEHSrAKsAFBCgqgABsFRBAaEK QVerEKBKC6sKABAKCgABqgpBtwqwCkG3qrAQdFkJQZe3sACqAAGqChAAqgoBqlQVlRaAIqhWraIq BF0sVVAEVSxdgC0EWlWFAFWqikoLQBF0sVQBAEsBQBUBVGlhQRWCLhRgAWDpwv8uQhVAYUEVAFYh 6HL7wygnrfbirDfvHRGCLrc/fKgKQReqEHS5/SFDVQi63IxVCLrcilUAiqDL7Q+jnLTay1AVgi63 P4xyKlQFiqDL7YAIQZfb36EqBF2oQtDlVqxC0OX2R1UIutyKVQCKoMvtD6OctNqLs968+w+GC0II utz+EKIqBF1ufxjlpBSVFoIutz+MctJqr0KlhaDL7Q+jnKi0ABRBl9sVEYIut39DVQi63N6oCkGX 2x/GhUoLQZfbH0Y5abUXZ7159x8MGYQQdLn9YZSTVntx1pt3/8FQpBBC0OX2h1FOWu3FWW/e/QdD cSTLCCEEXW5/GOWk1V6c9eb/3X8wFCuEEHS5/WGUk1Z7cdabd//BUBzJ8kEIQZfbH0Y5abUXZ715 9x8MRQshBF1ufxjlpNVenPXm3X8wFEeyfBBC0OX2h1FOWu3FWW/e/QdD8UIIQZfbH0Y5abUXZ715 9x8MxZEsG4QQdLn9YZSTVntx1pt3/8FQzBBC0OX2h1FOWu3FWW/e/QdDcSRLBiEEXW5/GOWk1V6c 9ebdfzAUM4QQdLn9YZSTVntx1pt3/8FQHMlyQQhBl9sfRjlptRdnvXn3HwzFDSEEXW5/GOWk1V6c 9ebdfzAUR7JUEELQ5faHUU5a7cVZb979B0NxQwhBl9sfRjlptRdnvXn3HwzF/5EsFYQQdLn9YZST Vntx1pt3/8FQ3BBC0OX2h1FOWu3FWW/e/QdDcSRLACEEXW5/GOWk1V6c9ebdfzAUO4QQdLn9YZST Vntx1pt3/8FQHMkSIQRdbn8Y5aTVXpz15t1/MBQ7hBB0uf1hlJNWe3HWm3f/wVAcyRIhBF1ufxjl pNVenPXm3X8wFDuEEHS5/WGUk1Z7cdabd//BUBxJEiEEXW5/GOWk1V6c9ebdfzAUP4QQdLn9YZST Vntx1pt3/8FQHMkRIQRdbn8Y5aTVXpz15t1/MBQ/hBB0uf1hlJNWe3HWm3f/wVAcyREhBF1ufxjl pNVenPXm3X8wFD+EEHS5/f9hlJNWe3HWm3f/wVAcyREhBF1ufxjlpNVenPXm3X8wFEGEEHS5/WGU k1Z7cdabd//BUBzJDyFdQtDl9odRTlrtxVlv3v0HQ7FDSAlBl9sfRjlptRdnvXn3HwzFkeQQ0iUE XW5/GOWk1V6c9ebdfzAUNYR0CUGX2x9GOWm1F2e9efcfDMWR5BDSRdDl9odRTlrtxVlv3v0HQ5FD SBdBl9sfRjlptRdnvXn3HwzFkeQQ0kXQ5faHUU5a7cVZb979B0ORQ0gXQZfbH0Y5abUXZ7159x8M xZHkEFJF0OX2h1FOWu3FWW/e/QdD0UNIFUGX2x9GOWm1F2e9efcfDMWR5BD/UkXQ5faHUU5a7cVZ b979B0PRQ0gVQZfbH0Y5abUXZ7159x8MxZHkEFJF0OX2h1FOWu3FWW/e/QdD8UNICUGX2x9GOWm1 F2e9efcfDMWR7BBSBF1ufxjlpNVenPXm3X8wFEGElBB0uf1hlJNWe3HWm3f/wVAcyQ4hRdDl9odR TlrtxVlv3v0HQzFESBF0uf1hlJNWe3HWm3f/wVAcyQ4hRdDl9odRTlrtxVlv3v0HQzFESBF0uf1h lJNWe3HWm3f/wVAcyQ4hQtDl9odRTlrtxVlv3v0HQ3FEiBB0uf1hlJNWe3HWm3f/wVAcyQ4hQtDl 9odRTlrtxVlv3v0HQ3FE/4gQdLn9YZSTVntx1pt3/8FQHMkOIQRdbn8Y5aTVXpz15t1/MBRHBSEE XW5/GOWk1V6c9ebdfzAUR5JDghB0uf1hlJNWe3HWm3f/wVAcFYQAAkGX2x9GOWm1F2e9efcfDMUx Q0KX2x8Bhi63OwJdbn8Y5aTVXpz15t1/MPyQ0OVmBF1ufxjlpNVenPXm3X8wFEEkdDkQdLn9YZQA hS4rgi63P4xy0movznrz7j8YOkioIuhyM4Yqgi63P4xy0movznrz7j8YihMSuoqgy+0Po5wUoNAN BF1ufxjlpNVenPXm3X/QQ0IRdLndUSiCLrc/jHLSai/OevPuPxiKChK6gf+gy+0Po5y0LhS6iqDL 7Q+jnLTai7PevPsPTkgogi63f0OhCLrc/jDKSau9OOvNu/9guCGhi6DL7Q+jnLRahkIXQZfbH0Y5 abUXZ7159x9ckAgEXW5/uFAEgi63P4xy0movznrz7j8YUkioIuhy+8MoJ632AhSqCLrc/jDKSau9 OOvNu/8cEoGgy+0PH4pA0OX2h1FOWu3FWW/e/QdDBwkNBF1ufxjlpNXeiUIDQZfbH0Y5abUXZ715 9/9CAkGX2x9GhQJBl9sfRjlptRdnvXn3HwyRUEXQ5faHUU5a7cULhSqCLrc/jHLSai/OevPuP4RE IOhy+8PIUASCLrc/jHL/0movznrz7j/IIaEIutz+MMpJq724olAEXW5/GOWk1V6c9ebdfwYJBF1u fxghCgRdbn8Y5aTVXpz15t1/EENCEXS5/WGUk1Z7cVYoFEGX2x9GOWm1F2e9efceiUDQ5faHUaII BF1ufxjlpNVenPXm3X9wQkIRdLn9YZSTVntxhigUQZfbH0Y5abUXZ7159xqJQNDl9odRKhSBoMvt D6OctNqLs968+w8+SCiCLrc/jHLSai/OFoUi6HL7wygnrfbirDfv3iIRCLrc/jBKhiIQdLn9YZST Vntx1pt3/0EGiUDQ5faHUU5a7cVZKxSBoMvtD6OctNqLs968e4oEgi63/z+M0qFA0OX2h1FOWu3F WW/e/QcVJAJBl9sfRjlptRdn7VAEgi63P4xy0movznrz7iMSCLrc/jBKiAJBl9sfRjlptRdnvXn3 H0QCQZfbH0Y5abUXZy1RIOhy+8MoJ6324qw37/4hEQi63P4wSogiEHS5/WGUk1Z7cdabd/87JAJB l9sfRjlptRdnTVEEgi63P4xy0movznrz7hsSCLrc/jBKiQJBl9sfRjlptRdnvXn3f0MiEHS5/WGU k1Z7cdYYRSDocvvDKCet9uKsN+9eIYGgy+0Po5wABYIutz+MctJqL8568+5/hgSCLrc/jHLSai/O egMUCLrc/jDKSau9OP/rzbsHSCDocvvDKCdAgaDL7Q+jnLTai7PevPuPIREIqjMIutz+EKAZBNWZ 3bXWWgqNIuhy+z80g6DL7d/QDAAMwiDocvs7FIGgy+0Po5y02ouz3rx3FIGgy+0Po5wARSDocvvD KCet9uKsN+/+W0gEgu7MLppBUJ3ZXWutBdAMgurM7lprrYVmEHS5/R+aQdDdGQRdbgc0AwCDMAA4 ugi6O4Ogyw0YgaDL7Q+jnLTai7PevHMUCLrc/jDKuVAg6HL7wygnrfbirDfv/ldIBIIuzCDozqyi GQRd3sFB0J1ZRTMIutzOaAZBl9vfoRkEXZ5B0OV2nAEA1YFgBkGXd3D/EHS5FSMQdLn9YZSTVntx 1pv3jQJBl9sfRjkXCgRdbn8Y5aTVXpz15t3/CgkEXcVRBVhFADiqAKsIdGYGQXVmFc0AqA4CmNHB ARxVAECYQdBlGJwZABxVAMBRGAAEmAFAmJkBBBxVAMDRAVCEGQTVmcVRBUVQxVEFWEUAOKoAigAz EAi63P4wykmrvTjrzftGgaDL7Q+jnAsFgi63P4xy0movznrz7n+FBIKuziDAjA4OgurMApoBUECA GQTVmVU0AwCKADMwOAAzgDMACggwg6DLMwgwA4MDMAM4A6CAADMIujCDADOqOAOggKMLADiDoDow CICjCqAIMKODAwAw/zgAM4AzAAoYCLrc/jDKSau9OOvN+0aBoMvtD6OcCwWCLrc/jHLSai/OevPu P4VEIOjqDALM6OAgqM4soBkARdDdGQTVmQU0A6CAMwAKOIOgCzMIujyDADMwOAiqM4ozAIqgiqMK oAgKM4ozoKoIMKMKaFRBEVRnFGcAFBAAZhBUZxRnIAJBl9sfRjlptRdnvXnPKAJBl9sfRjkXikDQ 5faHUU5a7cVZb979p5BA0NUZBJjRwUFQnVlAMwCKoLszCKozC2gGQAFnABRwBkEXZhB0eQYBZmBw EHRnBgcAZhAUZhRnABQQAGYAYQZmEGBGBwdBFUcVFEF1RnEGQAEBYP8GQXVGcQYCQZfbH0Y5abUX Z7153ygQdLn9YZRzoUDQ5faHUU5a7cVZb979r5BA0NUZBJjRwYEZAJwBBdWBQGFmcQZBdWYVjSqA IsAMDA6CLswgqM4szgAo4AyC6swqmkFQnVGcAVDAGVAAnAEFwBlQBF0YwAGYQVCdUZwBUMAZUARd HFUIBF1ufxjlpNVenPXmfaNA0OX2h1HOhQJBl9sfRjlptRdnvXn3v0IiEHRhBgFmFHAUAABHARRB d2ZwAGYQVGdW0QyCLo4qKIIqji7ADgKdmUGAGVVFowOgCLo4qgCAowCgigBmdHBgBkEXBnAAcHRB AWEGAHAUQBF0dwb/IxB0uf1hlJNWe3HWm/eNAkGX2x9GORcKBF1ufxjlpNVenPXm3X8LiUDQ5XZH Mwi6MIOgy604g6DL7Y9mEHS5FWcAFEGX2x9GOSlDM4Ggy+0Po5y02ouz3rxzFAi63P4wyrlQIOhy +8MoJ6324qw37/5fSASCLrc3mkHQ5fZGMwi63P4wLjQ6CLrc/jDKSRUanUDQ5faHUU5a7cVZb947 ikDQ5faHUU6AIhB0uf1hlJNWe3HWm3f/MSQQdLn9YZSTVntx1hugQNDl9odRTlrtxVlv3j1AAkGX 2x9GOQEKBF1ufxjlpNVenPXm3X8NiUDQ5faHUU5a7cVZYxSBoMvt/w+jnLTai7PevHtEFAi63P4w yglQIOhy+8MoJ6324qw37/5zSASCLrc/jHLSai/OmqIIBF1ufxjlpNVenPXmnSNSAgAMBF1ufxil RAFECLrc/jDKSau9OOvNu/8cEgi63P4wykmrvThriQJBl9sfRjlptRdnvXnfiBRBFyIQdLn9YZQQ RQAAISHocvvDKCet9uKsN+/+b0gEgi63P4xy0movztqhCARdbn8Y5aTVXpz15j0jUgRdhkDQ5faH UUIUCLpECLrc/jDKSau9OOvNu/8bEoGgy+0Po5y02ouzVigCQZfbH0Y5abUXZ715z4gIQZc7EHS5 /WGUDgWC7hIhIf/ocvvDKCet9uKsN+/+a0gogi63P4xy0movzhaFIuhy+8MoJ6324qw37xiRIuhy K0Yg6HL7wygZikDQZSUkIgRdbn8Y5aTVXpz15t3/DAlF0OX2h1FOWu3FGaJQBF1ufxjlpNVenPXm HSNSBF1uxwgEXW5/GKVCEQi63IqkCLrc/jDKSau9OOvNu/8ZEoqgy+0Po5y02ouzQqEIutz+MMpJ q7046817RkQIutzOKAJBl9sfRokiEHS5HYkQdLn9YZSTVntx1pt3/zUkFEGX2x9GOWm1F1cUiqDL 7Q+jnLTai7PevGdEiqDL7Q9QIOhy+8MIUSDocjsjIgRdbn8Y5aT/1V6c9ebd/w0JVQRdbn8Y5aTV XrxQqCLocvvDKCet9uKsN+8ZkSLocvs3FIGgy+0PI0MRCLrc/ogIQZfbH0Y5abUXZ715999DQgNB l9sfRjlptXei0EDQ5faHUU5a7cVZb945IkLQ5faHCgWCLrc/jAoFgi63P0NECLrc/jDKSau9OOvN u/8gEqoIutz+MMpJq70AhSqCLrc/jHLSai/OevPeESmCLrc/bCgCQZfbHz4UgaDL7f8QEYIutz+M ctJqL8568+4/uCChi6DL7Q+jnLRahkIXQZfbH0Y5abUXZ7159wohQtDl9ocRoAgEXW5/uFAEgi63 P1yICEGX2x9G/zlptRdnvXn3H3yQ0A0EXW5/GOWkdaHQVQRdbn8Y5aTVXpz15t07hAhBl9sfxoZC EXS5/RsKRdDl9ocPkSLocvvDKCet9uKsN+/+gxMSuoqgy+0Po5wUoNANBF1ufxjlpNVenPXm3VOE CEGX2x9GiUIRdLndUSiCLrc/jAwRIehy+8MoJ6324qw37/6DGRK6HAi63P4wSoBClxVBl9sfRjlp tRdnvXn3GSFC0OX2h1EyFKoIutyMoYqgy+0PI0SkCLrc/jDKSau9OOvNu/9giIQutz8CDF1udwS6 3P4wykmrvTjrzbv/DEKEoMvtD6OcKHS5GUGX2x9G6RARgi63P/+MctJqL8568+4/GIpIIOhy+8Mo J6324qw37/6DDUKEoMvtD6OcEwWCLrc/jHI6RISgy+0Po5y02ouz3rz7D4biSJbmiabq+iFECLrc /jDKSau9OANECLrc/jDKSau9OOvNu/9gKI5kaZ5oqq4dQgi63P4wykmrvTgzRAi63P4wykmrvTjr zbv/YCiOZGmeaKquGkKEoMvtD6OctNqLs0NECLrc/jDKSau9OOvNu/9gKI5kaZ5oqq4WQoSgy+0P o5y02ouzRISgy+0Po5y02ouz3rz7D4biSJbmiabqSiGEoMvtD6OctNqLc0VECLrc/jDKSau9OOvN u/9gKI5kaZ7/aKquEEKEoMvtD6OctNqLM0ZECLrc/jDKSau9OOvNu/9gKI5kaZ5oqq4NQgi63P4w ykmrvThrhYgQdLn9YZSTVntx1pt3/8FQHMnSPNFUXQGECEGX2x9GOWm1F2fdECHocvvDKCet9uKs N+/+g6E4kqV5oqmqIoSgy+0Po5y02ouzhogIQZfbH0Y5abUXZ7159x8MxZEszRNN1RMhBF1ufxjl pNVenPVEhKDL7Q+jnLTai7PevPsPhuJIluaJpiqJECHocvvDKCet9uKsKyIEXW5/GOWk1V6c9ebd fzAUR7I0TzRVRYQQdLn9YZSTVntx1hgRIehy+8MoJ6324qw3/+/+g6E4kqV5oqn6IYSgy+0Po5y0 2ouz3ogQdLn9YZSTVntx1pt3/8FQHMnSPNFU7RBC0OX2h1FOWu3FWW+FCEGX2x9GOWm1F2e9efcf DMWRLM0TTVUNIULQ5faHUU5a7cVZb4YIQZfbH0Y5abUXZ7159x8MxZEszRNNVQwhBF1ufxjlpNVe nPV+iBB0uf1hlJNWe3HWm3f/wVAcydI80VS1EELQ5faHUU5a7cVZ74gIQZfbH0Y5abUXZ7159x8M xZEszRNNVQohBF1ufxjlpNVenPWeiBB0uf1hlJNWe3HWm3f/wVAcydI80VSVEELQ5faHUU5a7cVZ 74oIQZfbH/9GOWm1F2e9efcfDMWRLM0TTVUIIQRdbn8Y5aTVXpz1vogQdLn9YZSTVntx1pt3/8FQ HMnSPNFUbRAiBF1ufxjlpNVenPXOiBB0uf1hlJNWe3HWm3f/wVAcydI80VRdEELQ5faHUU5a7cVZ b46IEHS5/WGUk1Z7cdabd//BUBzJ0jzRVEUIQZfbH0Y5abUXZ735QoSgy+0Po5y02ouz3rz7D4bi SJbmiaYoQgi63P4wykmrvTjrzRsiBF1ufxjlpNVenPXm3X8wFEeyNE80NRFC0OX2h1FOWu3FWW/+ ECHocvvDKCet9uKsN+/+g6E4kqV5ommJEIIutz+MctJqL87/enOICEGX2x9GOWm1F2e9efcfDMWR LM0TTUeEEHS5/WGUk1Z7cdabS0QIutz+MMpJq7046827/2AojmRpnmgaIoSgy+0Po5y02ouz3pwi QtDl9odRTlrtxVlv3v0HQ3EkS/NEUxAhBF3ewkLQ5faHAFUhqFbtrrXWUqgUQZfb/6EqBF1u/4aq AKAQCqAKQZfbsRQAtBDocrsiQtBlKCwEXW5/CFAVgmrV7lprLYVKEXS5/R+qQtDl9m+oCgAKoQCq EHS5HUsRdLn9YZSTVntx1pt3/8FQHC+EEHSZCwtBt2oVVSHocjugKgTVqt211loLVSHocvs/VIWg u1UIutwO/6gKAAqhAKoQdLkbq0ABEKoQdLl9ESHochWCbtUqqkLQ5XZAVQiqVbtrrbUWqkLQ5fZ/ qApBd6sQdLkdUBUAFEIBVCHocjdWgSLocvvDKCet9uKsN+/+g6E4Vggh6HIXFoJu1SqqQtDlLSwE 3apVVIWgy+2MqhB0uf0dqkLQ5SoEXW7HKgBQLQiqEHS5G6sQdKsQdLmdESHobhWCbtUqqkLQ5S0s BN2qVVSFoMvtjKoQdLn9HapC0OUqBF1uxyoAUC0IqhB0uRurEHS5/WGUk1Z7cdabd//BUBwxhBB0 ubFUAVYRAJYqwCoCrapCUK1aRVUAqoUAqrSwAEsVABCqEP90GQqrCgBLFQCwFAoAAaoAEKqqAAFL FQCwtAAUoQpBtWqxVGEVAbBUAQBLCwCwCkG3agGVFsAqAq0qwAIgBN3FUgVYRQBYqgCrCLSqCkG1 ahVVAagWAqjSwgIsVQBAqELQZSisKgAsVQDAUigABKgCQKiqAgQsVQDA0gJQhCoE1arFUoVVBMBS BQAsLQDAKgRdbn8Y5aTVXpz15t1/MBTHCyEEXW7AKgAFhCoE1aoFVAWggABVCKpVq6gKABQBqqCw AKoAqwAUEKAKQZerEKAKCgugCrAKQAEBqhB0oQoBqlSxCkABSxcAsApBtaAQoEoLC6oAsAoUAKtA FUG1ahf/oCpQAKwCBcAqACAEXa1CgCotLATVqgVUBaCAAFUIqlWrqAoAFAGqoLAAqgCrABQQoApB l6sQoAoKC6AKsApAAQGqEHShCgGqVLEKQAFLFwCwCkG1oBCgSgsLqgCwChQAq0AVQZfbH0Y5abUX Z7159x8MxbFCCEGXW7EKQAGhCkG1agFVASiC7lYhqFYtoCoABawCUMAqBF2oQtDlKgSogsJCUK1S rAJQBFUsVQBFUKhSrAJVRYAqVUClCgoIVVCFoIqlC6AIulULqFRBAaEKqhCgShUJQReqEKBKCwtB tWoBVQEogu5WIahWLaAqAAWsAlDAKgRdqELQ5SoEqILC/0JQrVKsAlAEVSxVAEVQqFKsAlVFgCpV QKUKCghVUIWgiqULoAi63P4wykmrvTjrzbv/YCiOFkIIutyKVQAKCFUIqlULqApAEXS3CkG1agFV AShgFYACViHoQhWCLlchQBUUFoJuVWEBQBWCQpViFYACAkAVIFRBFQJUaWEhqGKpggJCFVQhqFbt oioE3arFKgAFrAJQQKiqQlClXUBVAAoIVQiqVQuoCkARdLcKQbVqAVUBKGAVgAJWIehCFYIuVyFA FRQWgm5VYQFAFYJClWIVgAICQBUgVEEVAlRpYSGoYqmCAkIVVCGoVu2iKgRdbn8Y5aTVXpz15t1/ MBTHCv8hBF3uxSoABYQqqEKAKigswFIFAIQqAMAqBNWqVVSqAIoAVVBYCLpQhaBatVgFoIBVCKpV q6gKQbVKsQpAAatAAbAKFACrQBF0oQALoAoQqqAKQbVKsQpAEXSrFqsAFLAKQAGrEHSXWFEVgAJC FVQhQBUUFmCpAgBCFQBgFYJq1SoqVQBFgCooLARdqEJQrVqsAlDAKgTVqlVUhaBapVgFoIBVoABY BQqAVaAIulCABVAFCFVQhaBapVgFoAi63P4wykmrvTjrzbv/YCiOFUIIutyLVQAKCFBVgABQVQhQ paqotAAUQbVqFVUh6GKpgiKoYukCbCHQqioEqFJVVFr/AIqgi6UKAFgKAKoIoEoLC6oQdKEAC6AK EKqgCkG3qrAAoApBAUsXYBVBFUBhAVQVFoIu7WIVgAICVBUgAFQVAlSpKiotAEVQrVpFVQi6WKqg CKpYugBbCLSqCgGqVBWVFoAi6GKpAgCWAoAqAqjSwoIqBF0owAKoAoQqqELQrSosAKhC0OX2h1FO Wu3FWW/e/QdDcawQQtDl9ocLVSHoQhWCLrdiFYIutz+qQtDlVqwCUARdbn8Y5aQVoioARdAlBF1u b1SFoAtVCLrcilUIutz+qApBl1uxCkARdLn9YZSTVntx1pt3/8FQHMmyRAhBl9sfMlSFoMvtjaoQ dLn9/2FcqLQQdLn9YZSTVolKC0EXiJkxxhSqQtDl9kZVCLrc/jAuVFoIutz+MMpJq7046827/2Ao jmRpIoSgy+0Po5y02ouz3rwzRAi63P4wykmrvTjrzbv/YCiOZGmeaDohhKDL7Q+jnLTai7PevDNE CLrc/jDKSau9OOvNu/9gKI5kaZ5oKiGEoMvtD6OctNqLs968O0QIutz+MMpJq7046827/2AojmRp nmgaIYSgy+0Po5y02ouz3rw7RAi63P4wykmrvTjrzbv/YCiOZGmeaAohhKDL7Q+jnLTai7PevENE CLrc/jDKSau9OOvNu/9gKI5kaZ5o+iCEoMvtD6OctP/ai7PevENECLrc/jDKSau9OOvNu/9gKI5k aZ5o6iCEoMvtD6OctNqLs968S0QIutz+MMpJq7046827/2AojmRpnmjaIISgy+0Po5y02ouz3rxL RAi63P4wykmrvTjrzbv/YCiOZGmeaNoghKDL7Q+jnLTai7PevEtECLrc/jDKSau9OOvNu/9gKI5k aZ5oyiCEoMvtD6OctNqLs968U0QIutz+MMpJq7046827/2AojmRpnmi6IISgy+0Po5y02ouz3rxT RAi63P4wykmrvTjrzbv/YCiOZGmeaLoghKDL7Q+jnLTai7PevFNECLrc/jDKSau9OOvNu/9gKI5k aZ7/aLoghKDL7Q+jnLTai7PevFdECLrc/jDKSau9OOvNu/9gKI5kaZ5oqiCEoMvtD6OctNqLs968 V0QIutz+MMpJq7046827/2AojmRpnmiqIISgy+0Po5y02ouz3rxXRAi63P4wykmrvTjrzbv/YCiO ZGmeaKoghKDL7Q+jnLTai7PevFtECLrc/jDKSau9OOvNu/9gKI5kaZ6oiRABIehy+8MoJ6324qw3 7xcRECHocvvDKCet9uKsN+/+g6E4kqV5oiNCugi63P4wykmrvTjrzTtFpIqgy+0Po5y02ouz3rz7 D4biSJbmiY4I6SqCLrc/jHLSai/OevMOEekSgi63/z+MctJqL8568+4/GIojWZonOiKkSwi63P4w ykmrvTjrzbtEpIugy+0Po5y02ouz3rz7D4biSJbmiY4I6RKCLrc/jHLSai/OevMuEeki6HL7wygn rfbirDfv/oOhOJKleaIjQroIutz+MMpJq7046807RaSKoMvtD6OctNqLs968+w+G4kiW5omOCOki 6HL7wygnrfbirDfvFJEqgi63P4xy0movznrz7j8YiiNZmic6IqSKoMvtD6OctNqLs968W0RKCLrc /jDKSau9OOvNu/9gKI5kaZ7oiJAqgi63P4xy0movznrzbhEpIehy+8MoJ6324qw37/6DoTiSpXmi I/9CSgi63P4wykmrvTjrzTtGpAi63P4wykmrvTjrzbv/YCiOZGme6IiQIuhy+8MoJ6324qw37xmR Iuhy+8MoJ6324qw37/6DoTiSpXmiI0KKoMvtD6OctNqLs968a0SEoMvtD6OctNqLs968+w+G4kiW 5omOCBGCLrc/jHLSai/OevO+ERGCLrc/jHLSai/OevPuPxiKI1maJzoiRAi63P4wykmrvTjrzTtH hKDL7Q+jnLTai7PevPsPhuJIlubpIaHL7Q8DIgxdbv+HQJfbH0Y5aUOhy+0Po5y02msRYehy+8Mo J6324odAl9sfRjlptRdnvXn3HwxFEAkEXW5/GOX/bCgQdLn9YZSTNhQIutz+MMpJq7046827/0gg 6HL7wygnrfbirDfv/oOhCCKBoMvtD6OcDQWCLrc/jHLShgJBl9sfRjlptRdnvXn3HwkEXW5/GOWk 1V6c9ebdfzAUQSQQdLn9YZSzoUDQ5faHUU7aUCDocvvDKCet9uKsN+/+I4Ggy+0Po5y02ouz3rz7 D4YiiASCLrc/jHI2FAi63P4wykkbCgRdbn8Y5aTVXpz15t1/JBB0uf1hlJNWe3HWm3f/wVAEkUDQ 5faHUc6GAkGX2x9GOWlDgaDL7Q+jnLTai7PevPuPBIIutz+MctJqL8568+4/GIogEgi63P4wytlQ /yDocvvDKCdtKBB0uf1hlJNWe3HWm3f/kUDQ5faHUU5a7cVZb979B0MRRAJBl9sfRjkbCgRdbn8Y 5aQNBYIutz+MctJqL8568+4/Egi63P4wykmrvTjrzbv/YCiCSCDocvvDKGdDgaDL7Q+jnLShQNDl 9odRTlrtxVlv3v1HAkGX2x9GOWm1F2e9efcfDEUQCQRdbn8Y5WwoEHS5/WGUkzYUCLrc/jDKSau9 OOvNu/9IIOhy+8MoJ6324qw37/6DoQgigaDL7Q+jnA0Fgi63P4xy0oYCQZfbH0Y5abUXZ7159x8J BF1ufxjlpNVenPXm3X8wFEEkEHS5/WGUs6FA0P/l9odRTtpQIOhy+8MoJ6324qw37/4jgaDL7Q+j nLTai7PevPsPhiKIBIIutz+McjYUCLrc/jDKSRsKBF1ufxjlpNVenPXm3X8kEHS5/WGUk1Z7cdab d//BUASRQNDl9odRzoYCQZfbH0Y5aUOBoMvtD6OctNqLs968+48Egi63P4xy0movznrz7j8YiiAS CLrc/jDK2VAg6HL7wygnbSgQdLn9YZSTVntx1pt3/5FA0OX2h1FOWu3FWW/e/QdDEUQCQZfbH0Y5 GwoEXW5/GOWkDQWCLrc/jHLSai/OevPuPxIIutz+MMpJq7046827/2Aogkgg6HL7wyhnQ4Ggy+3/ D6OctKFA0OX2h1FOWu3FWW/e/UcCQZfbH0Y5abUXZ7159x8MRRAJBF1ufxjlbCgQdLn9YZSTNhQI utz+MMpJq7046827/0gg6HL7wygnrfbirDfv/oOhCCKBoMvtz9AMgi63PwQoEHS5/WGUkzYUCKoz CLrc/hCgGQTVGQRdbn8I0CiCLrc/dGgGQXVmdy00g6DL7d/QDIIuN+MMgi434wyCLrc/bCgQdLn9 YZSTVntx1pt3/8FQBJFA0OX2Z2gGQZfbHwIUCLrc/jDKSRsKBNWZXTSDoDqzu9ZaC6AZBNUZBF1u f6jQDIIutz90aAZBdWZ3LTQDoIqgMzMIOjOD/6AzMwi6M4szAAA4Ogi6M4szAAA4Ogi6M4qjAwA4 g6DLzTg6AICjEwi63P4wykmrvTjrzbv/YCiCSCDocvszNIOgy+0PAQoEXW5/GOWkDQWC6swumkFQ ndldC6AZBN2ZVTSDoMvtDxeaQdDl9ocNzSDozuwuhWYAFBBmYAYBZmBwAGYAZwAUEABmAAFmBhBg BgBnAABwBgB0EOiMDg4AwOAAzADCDMDgIOhyL84AKOAMgCLocvvDKCet9uKsN+/+g6EIIoGgy+0P 0KgC7CDQ5fZfKBB0uf1hlJM2FAiqOKoAqwgARxVgFYHOzCCozqyiGQBQRQAzOjgAM4MDMAM4A/+g OggUZhbQ6CDo8gzOAOCoAgCOwgAgwAwAAo4qwA4C1RnFGQAFnAFQwBkARVCdWUAzAAM4AwCKADOq OAMwgDMIujCDoDCjOAOggKMKADg6AIowAzA4ADMIqjMIutz+MMpJq7046827/2Aogkgg6HL7oxkA BZwBUARdbn+FAkGX2x9GOWlDgaA6ozgDoAiqMwtoBkABAWYQVGdW0QwAKALMwOAAzCCozgCOLigg zAAAzgCAIsCMqio0A6CAMwAKOAOggAAzAAgzAIMDMwA4AwCKoAszCDMwgwMzMDgDMIMzAAA4g6A6 swvQDAAogurMAhodAECYAQCcAVBAmAEAhBn/gMEBHF1QwFEAVQwEXW5/GOWk1V6c9ebdfzAUQSQQ dLn90QyAAo4ugi63v0KBoMvtD6OctKFAUJ1RnAFQBNWZBTQDoAi6O4OgOrOARhdgB4HiqMIuwgzA 4ADADILi6CLo6gwCzMDgIKjOKM4AKCAAzADCDODoAiiC7swgwMwAzoAO4AyC6oziDILuzCoaBQBF 0J3ZBWgGQAEBAEcXQBEUZhRnQFURZgYGB0F1BkGX2x9GOWm1F2e9efcfDEUQCQRdbn80A6CAMwi6 3P4OBYIutz+MctKGAkF1RnEGQBFUZxbQDIAi6O4MgurMAppB0J0ZHIAZQJiBGQSYgcEBmAEE/5gB QJhB0GUdHIAZwBkE3ZnBAYAZBIUZxRlQBN2ZVTQDAIAzAAo4A6AIqjOKMwi6MwtoBkF1ZhfNIOjC DALMqOIMgALCDAAgzAAMDswA4AwoAM4gqM4g6HL7wygnrfbirDfv/oOhCCKBoMvtj2YAFHAGQBF0 uf0VCgRdbn8Y5aQNBYLqjOIMgALOACjgDKgOgsLM4gyC6swqmgFQwBkABZwBUMAZAAUcVQBAmAEA nAFQQIAZAIQZgMGBGQTVmVU0g6A6ozgDCoAzoAiqM6toBkABZwAUcAZAAWcQdGEGQWdUAc0g6MIM gs7o4MAMguqM4gyAAs6AAuAMKADOgALgDP8oAM4g6HL7wygnrfbirDfv/oOhCCKBoMvtD9CoAuwg 0OX2XygQdLn9YZSTNhQIqjOKMwCgg0BhZhBgRlXR6AAogurMLhodAEWAGcVRBQWEGZhBUMXRBdhB oDMzCDozgwAzqopGB0ARdHFUAXYQwIwqoNEF2EGgMzMIOjODADOqgEYXdhFmEFRxdAF2EMCMKqAZ AAUEmBlAgJkZBJjRwQGYGRwAmMGZQNDl9odRTlrtxVlv3v0HQxFEAkGX2x9GORsKBF1ufxjlpA0F gi63N5pB0IUZBF1ufxjRDIIut+MMgi634gyAIuhy+8MoJ632YokCQZfbH0Y5abUXZ7159x//DEUQ CQRdbn8Y5WwoEHS5/WGUkzYUCLrc3mgGQZfbH8aIZhB0uf1hQ6ODoMvtD6OctNqLJwoEXW5/GOWk 1V6c9ebdfzAUQSQQdLn9YZSzoUDQ5faHUU7aUCDocvvDKCet9uKsN+/+I4Ggy+0Po5y02ouz3rz7 D4YiiASCLrc/jHI2FAi63P4wykkbCgRdbn8Y5aTVXpz15t1/JBB0uf1hlJNWe3HWm3f/wVAEkUDQ 5faHUc6GAkGX2x9GOWlDgaDL7Q+jnLTai7PevPuPBIIutz+MctJqL8568+4/GIogEgi63P4wytlQ IOhy+8MoJ20oEHS5/WGUk1Z7cdabd/+R/0DQ5faHUU5a7cVZb979B0MRRAJBl9sfRjkbCgRdbn8Y 5aQNBYIutz+MctJqL8568+4/Egi63P4wykmrvTjrzbv/YCiCSCDocvvDKGdDgaDL7Q+jnLShQNDl 9odRTlrtxVlv3v1HAkGX2x9GOWm1F2e9efcfDEUQCQRdbn8Y5WwoEHS5/WGUkzYUCLrc/jDKSau9 OOvNu/9IIOhy+8MoJ6324qw37/6DoQgigaDL7Q+jnA0Fgi63P4xy0oYCQZfbH0Y5abUXZ7159x8J BF1ufxjlpNVenPXm3X8wFEEkEHS5/WGUs6FA0OX2h1FO2lAg6HL7wygnrfbirDfv/iOBoP/L7Q+j nLTai7PevPsPhiKIBIIutz+McjYUCLrc/jDKSRsKBF1ufxjlpNVenPXm3X8kEHS5/WGUk1Z7cdab d//BUASRQNDl9odRzoYCQZfbH0Y5aUOBoMvtD6OctNqLs968+48Egi63P4xy0movznrz7j8YiiAS CLrc/jDK2VAg6HL7wygnbSgQdLn9YZSTVntx1pt3/5FA0OX2h1FOWu3FWW/e/QdDEUQCQZfbH0Y5 GwoEXW5/GOWkDQWCLrc/jHLSai/OevPuPxIIutz+MMpJq7046827/2Aogkgg6HL7wyhnQ4Ggy+0P o5y0oUDQ5faHUU5a7cVZb979RwJBl9v/H0Y5abUXZ7159x8MRRAJBF1ufxjlbCgQdLn9YZSTNhQI utz+MMpJq7046827/0gg6HL7wygnrfbirDfv/oOhCCKBoMvtD6OcDQWCLrc/jHLShgJBl9sfRjlp tRdnvXn3HwkEXW5/GOWk1V6c9ebdfzAUQSQQdLn9YZSzoUDQ5faHUU7aUCDocvvDKCet9uKsN+/+ I4Ggy+0Po5y02ouz3rz7D4YiiASCLrc/jHI2FAi63P4wykkbCgRdbn8Y5aTVXpz15t1/JBB0uf1h lJNWe3HWm3f/wVAEkUDQ5faHUc6GAkGX2x9GOWlDgaDL7Q+jnLTai7PevPuPBIIutz+MtHLSai/O evPuPxiKIBK63P4wyvkQ6HL7wygnbSh0uf1hlJNWe3HWm3f/FQR0uf1hlJNWe3HWm3f/wVAcydI8 0VRd2dZ94Vie6dq+8Vzf+d7/gUHhkFg0HpFJ5ZLZdD6hUemUWrVesVntltv1fsFh8ZhcNp/RafWa 3Xa/4XH5nF633/F5/Z7f9/8BAwUHCQsNDxETFRcZGx0fISMlJykrLS8xMzU3OTs9P0FDRUdJS01P UfEQEgA7 --Apple-Mail-6-384816202 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit which is what I started off with. Henry Story On 10 Jan 2005, at 19:11, Henry Story wrote: > > Ok, I give up on this task. > > I have just found that when there is a rdf:Resource you can't also > have attributes. And that attributes have to be qualified. > > It is a real pity. > > It would be good to make a list of what we would have needed from > RDF/XML to make Atom be rdf, and then work backwards to create > RDF/XML2 where this works out fine. > > Henry > > On 10 Jan 2005, at 01:29, Robert Sayre wrote: >> Henry Story wrote: >> >>> [snip] >>> 4) Property attributes >>> ---------------------- >>> >>> both hreflang, href and all the other properties of Link are unique, >>> and given that they are string literals (subsets of them at least, >>> but nevertheless) they can be move into attributes on Link >>> >>> >>> >> hreflang="de" >>> href="http://example.org/de/2003/12/13/Atom03"/> >>> >> >> >> Use of unqualified attributes is deprecated in RDF/XML (check the >> validator). My opinion is that the transformation you're looking for >> would be easier with XSLT. > > You are right. The validator at is > really useful. > > [snip] > >>>> >>>> It gets a POST with a fairly average atom entry, but there are >>>> extensions in funny places. Like most people, the server stores >>>> standard fields in a relational database, so there are columns for >>>> title, summary, etc. in a table called something like >>>> "journal_entries". It would be fairly easy to store immediate >>>> children of entry in an "unknown_xml" field, and pass them >>>> through, but what about the other extensions? Using an RDF store >>>> might make this problem a lot easier, but I don't forsee a mass >>>> migration in that direction happening this year or next. >>> >>> >>> You don't need a specialized RDF storage, though very good ones >>> exist. There are schemes to map RDF into any relational database, >>> just as there are schemes to map objects into relational databases. >>> In fact most RDF storage tools in Java provide this. >> >> >> That's not my point. My point is that there's a staggering amount of >> data currently living in RDBMSes, and people aren't going to >> re-architect their storage to use Atom. > > I was not trying to get people to use RDF databases at the back end. I > was just hoping that a well engineered XML document would with a > little care also turn out to be a well engineered RDF document. That > would provide maximum flexibility in that it would allow people to > move into the rdf world seamlessly. > > >> Robert Sayre >> > --Apple-Mail-6-384816202-- From owner-atom-syntax@mail.imc.org Mon Jan 10 20: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 UAA22102 for ; Mon, 10 Jan 2005 20: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 j0B1Isrk028373; Mon, 10 Jan 2005 17:18: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 j0B1Ist8028372; Mon, 10 Jan 2005 17:18: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 j0B1IqF8028336 for ; Mon, 10 Jan 2005 17:18:52 -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, 11 Jan 2005 14:18:10 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 11 Jan 2005 11:55:50 +1100 Subject: Re: PaceFeedRecursive From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1f2ed5cd0501101159dcab0bf@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 11/1/05 6:59 AM, "Danny Ayers" wrote: > Ok, I don't think there is any benefit in the normal case (feed ::= > meta, (meta, content)*), but the recursive nesting method makes it > possible to convey information about relationships between feeds. > Which begs the questions: > > How useful are the semantics of one feed containing another? > How desirable is it to convey such information in Atom format? Would not the element set which describes a resource be an entry, regardless of whether that resource is an html page, image/jpg, rss 0.91 feed, atom feed, etc? With our element, we are able to clearly communicate that a resource we link to is of type application/atom+xml. Surely, if someone wanted to build the equivalent of an OPML file in Atom format, they could do so simply by creating an entry for each feed ... where any of those feeds could also be of the same OPML equivalent class, thus giving you deep nesting if you really want it. Alternatively, shallow nesting is possible by the presence of multiple elements within an entry, possibly with @rel="DC.refined" or whatever the DC term is. I note that the Nature Publishing Group already have something similar: http://npg.nature.com/pdf/newsfeeds.rdf e. From owner-atom-syntax@mail.imc.org Mon Jan 10 21:41: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 VAA27294 for ; Mon, 10 Jan 2005 21:41: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 j0B2RNJE034975; Mon, 10 Jan 2005 18: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 j0B2RNMM034974; Mon, 10 Jan 2005 18:27: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 j0B2RL95034968 for ; Mon, 10 Jan 2005 18:27: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); Tue, 11 Jan 2005 15:28:08 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 11 Jan 2005 13:27:26 +1100 Subject: atom entry documents, feed alternates, mime-types 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 I've realised another use case for atom entry documents. I'm using del.icio.us to track certain memes. For example: http://del.icio.us/tag/atom http://del.icio.us/tag/rss http://del.icio.us/tag/folksonomy For each of those pages they offer an RSS feed. The feed's entries contain the bookmarked page title, the URL, and the brief comment entered by the bookmarkee, if any. Unfortunately, this means that in my feed reader I'm seeing just headlines and links, no summary, no content. What would be really neat is if del.icio.us were able to follow a in the html page to discover an Atom , and use the element. This would be similar in how citeulike (similar to del.icio.us, but geared for academics) extracts the citation details from academic papers. To attempt to do so with currently deployed best practice is problematic: a blog page may well have a , but that is most likely to point the ongoing feed, not the item alternate in xml. While there is a chance that that particular page is in the current feed, it's quite possible that it has already dropped off the bottom. Even if del.icio.us wanted to serially download the history of that feed looking for that entry, it would be an immense bandwidth waste, and we haven't settled on any concrete conventions for the format to communicate where archives can be found. Life would be so much easier if there was also a on the html page which lead directly to a standalone Atom Entry document. Well, easier except for a couple of bumps in the road. What @rel would we use on the entry page ... "alternate" is already taken to mean "the feed in which this entry was once found". Perhaps we need a different @type value for Atom Entry documents, to distinguish them from Atom Feed documents? That, or we try using a different @rel ("feed"?) to identify the feed (while still allowing the html page whose contents change as new entries come and go being able to legitimately refer to the Atom Feed document as it's "alternate"). Come to think of it, if there will exist things like "feeds of feeds", which act as directories of feeds offered by a site, then the html page whose content reflects the most recent entries should then have a link to the directory/collection feed, in the same way that individual pages would. Thus, on an entry html page it would be mighty nice to find this: and on the most-recent-posts page it would have this where: [1] is the atom entry document for that page [2] is the feed in which this entry/page was once announced [3] is the atom feed document which is the alternate for this page [4] is the atom feed document which is the site directory of feeds Note how [3] is distinguished from [1]. For backwards compatibility we should also allow the following on an entry html page: In summary, the del.icio.us situation suggests great usefulness in having individual atom entry documents being more widespread, which might just help popularising the atom feed format at the same time. The other feed formats don't really have this feature of being able to point to a resource which is the item and just the item, in machine readable xml. It's probably doable in RDF though, so RSS 1.0 kinda has I, but we all know there are perceptions of popularity problems with it. If we want to use atom entry documents as page metadata resources, then we need to make a couple of changes as outlined above. e. From owner-atom-syntax@mail.imc.org Tue Jan 11 02:20: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 CAA24487 for ; Tue, 11 Jan 2005 02:20: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 j0B74La7011814; Mon, 10 Jan 2005 23:04: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 j0B74LuQ011813; Mon, 10 Jan 2005 23:04:21 -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 j0B74KOs011785 for ; Mon, 10 Jan 2005 23:04:20 -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 27DE44EFED for ; Tue, 11 Jan 2005 02:04:25 -0500 (EST) Message-Id: <6.0.0.20.2.20050111160057.07a79310@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 11 Jan 2005 16:04:16 +0900 To: Atom WG From: Martin Duerst Subject: PaceIRI 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 I have completed (as far as I'm concerned) PaceIRI. The proposal is simple, namely to allow IRIs wherever the spec currently allows URIs. I have given details of what needs to be changed in the spec for that to happen. If anything is unclear, I'm glad to help out the editors. As far as I remember, the main objection on previous discussions of IRIs was that the IRI spec was not yet approved. But it is approved now. If there are other objections, please say so. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Jan 11 02: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 CAA26858 for ; Tue, 11 Jan 2005 02:59: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 j0B7opXJ072624; Mon, 10 Jan 2005 23:50: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 j0B7opoa072623; Mon, 10 Jan 2005 23:50:51 -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 j0B7oohi072614 for ; Mon, 10 Jan 2005 23:50:50 -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 8E1884EFED; Tue, 11 Jan 2005 02:50:56 -0500 (EST) Message-Id: <6.0.0.20.2.20050111163947.07a77f10@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 11 Jan 2005 16:46:35 +0900 To: Robert Sayre , Graham From: Martin Duerst Subject: content for text/ or +xml SHOULD be local? (was: Re: Hash for Links) Cc: James Snell , Atom WG , Tim Bray In-Reply-To: <41E049A8.1050903@franklinmint.fm> References: <1f2ed5cd050105162514f7773f@mail.gmail.com> <1f2ed5cd050106050455c75c9d@mail.gmail.com> <2bcdc7c405010609374df235f3@mail.gmail.com> <41E0464A.6090802@franklinmint.fm> <41E049A8.1050903@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 At 05:59 05/01/09, Robert Sayre wrote: >http://atompub.org/2004/10/20/draft-ietf-atompub-format-03.html#rfc.section.5.10.2 > >"If the value of type begins with "text/" or ends with "+xml", the content SHOULD be local; that is to say, no "src" attribute should be provided." > >If you want to suggest language that describes the bad things that could happen when people ignore that recommendation, I would be happy to include it. When I read this, I was somewhat surprised to find a SHOULD. A should, in IETF terms, is really quite strong. I'd prefer a wording such as: "In general, content with value of type beginning with "text/" or ending with "+xml" will be inline; that is to say, no "src" attribute is provided." (and I think inline is the better term; local implies on the user's machine rather than inside the document) In both cases, adding something like "Such content is usually short, and in that case, carrying it inline is more efficient." covers the rationale I know about. There may be other rationales. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Jan 11 02:59: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 CAA26875 for ; Tue, 11 Jan 2005 02:59: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 j0B7orvk072657; Mon, 10 Jan 2005 23: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 j0B7or3B072656; Mon, 10 Jan 2005 23:50:53 -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 j0B7orWc072648 for ; Mon, 10 Jan 2005 23:50:53 -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 57B894EFF2 for ; Tue, 11 Jan 2005 02:50:59 -0500 (EST) Message-Id: <6.0.0.20.2.20050111165014.07a77c90@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 11 Jan 2005 16:50:56 +0900 To: Atom WG From: Martin Duerst Subject: Re: PaceIRI In-Reply-To: <6.0.0.20.2.20050111160057.07a79310@localhost> References: <6.0.0.20.2.20050111160057.07a79310@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 16:04 05/01/11, Martin Duerst wrote: > >I have completed (as far as I'm concerned) PaceIRI. Just to help everybody to look at it faster, here is the URI/IRI: http://www.intertwingly.net/wiki/pie/PaceIRI Sorry I forgot. >The proposal is simple, namely to allow IRIs wherever the spec >currently allows URIs. I have given details of what needs to be >changed in the spec for that to happen. If anything is unclear, >I'm glad to help out the editors. > >As far as I remember, the main objection on previous discussions >of IRIs was that the IRI spec was not yet approved. But it is >approved now. If there are other objections, please say so. > > >Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Jan 11 04:56: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 EAA07658 for ; Tue, 11 Jan 2005 04: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 j0B9frEm091219; Tue, 11 Jan 2005 01: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 j0B9frZt091217; Tue, 11 Jan 2005 01:41:53 -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 j0B9fmKI090984 for ; Tue, 11 Jan 2005 01:41:48 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 29765 invoked by uid 17064); 11 Jan 2005 09:41:57 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.253.244.73]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 11 Jan 2005 09:41:57 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <1f2ed5cd04122009457048a39c@mail.gmail.com> References: <200412201637.CEP57803@ms8.netsolmail.com> <8C202490-52AA-11D9-BCBC-000A95D9FA7A@bblfish.net> <1f2ed5cd04122009457048a39c@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <06C65E5B-63B5-11D9-8C94-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: "Role of RSS in Science Publishing": Atom is in RDF format Date: Tue, 11 Jan 2005 10:41:53 +0100 To: atom-owl@googlegroups.com, "'Atom WG'" X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Just found this mail and thought it worth replying to. It points out a little bug with the Ontology I just released lately. I made the entry id inverse functional. That won't do. If id is inverse functional, then given two entries with the same id _f1----a-----> |---entry--> _e1 ---a-----> | |-----id----> | |---title---> "first verzion of the entry" | |-published-> "20 Dec 2004" |... _f1----a-----> |---entry--> _e2 ---a-----> | |-----id----> | |---title---> "second version of the entry" | |-published-> "10 Jan 2005" |... One would have to conclude that the anonymous nodes _e1 and _e2 were the same. Ie -----1/id-------> _e the inverse of id (called 1/id) can only have one value. But if we tried to do this we would have to conclude that the entry with , called _e had two publication dates. Yet an Entry can only have at most one. So we end up with a contradiction by making id inverse functional. By simply making it functional we bypass that problem, and we have correctly model what we had: namely we have two Entries with the same id, which one can think of as two versions of the same entry. On 20 Dec 2004, at 18:45, Danny Ayers wrote: > ... > Some of the possible approaches for an RDF/XML expression of the info > include (ignoring namespace decls & case!): > > RSS 1.0 style: > > > > ... > > Stuff > ... > > ... > this would be equivalent to making id inverse functional. If you do this then you have the merging problem explained above. > > ------------------------------------- > > A bit more plain-XMLy : > > > > ... > > > Stuff > ... > > ... > > ... > yes this just groups the entries in an "entries" tag. I don't see that it adds much. (I know you are just pointing out all the different ways one can do this) > > ---------------------------- > > Lumpier: > > > ... > > > Stuff > > > ... > note: the RDF people think that having properties named hasXXX is quaint. Or so at least DanC told me on #irc quite a few months ago. > ------------------------------ > > Closer to Atom 0.3 : > > > ... > > vemmi://example.org/2003/32397 > Stuff > ... > > ... > This is exactly right, except that id should absolutely not be inverse functional. Just functional will do :-) > > The last is kind of interesting, having the id attached to a blank > node. If id were spec'ed as an inverse functional property that might > work nicely. > > But as far as I can tell none fit too well with : > > > > Cheers, > Danny. > > -- > > http://dannyayers.com > From owner-atom-syntax@mail.imc.org Tue Jan 11 06:42: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 GAA14549 for ; Tue, 11 Jan 2005 06: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 j0BBQovc048109; Tue, 11 Jan 2005 03:26: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 j0BBQoIg048108; Tue, 11 Jan 2005 03:26: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 j0BBQoR9048101 for ; Tue, 11 Jan 2005 03:26:50 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 61041 invoked by uid 17064); 11 Jan 2005 11:26:59 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.253.244.73]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 11 Jan 2005 11:26:59 -0000 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'Atom WG'" From: Henry Story Subject: Atom DTD? Date: Tue, 11 Jan 2005 12:26:57 +0100 To: atom-owl@googlegroups.com X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Is there a DTD available for the current spec? Or something similar? Otherwise how could I specify the equivalent of in the spec? I suppose we just say something like: the head element has a hidden default attribute of rdf:parseType with a fixed value of "Resource" Henry Story From owner-atom-syntax@mail.imc.org Tue Jan 11 07: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 HAA17816 for ; Tue, 11 Jan 2005 07: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 j0BCOND1072121; Tue, 11 Jan 2005 04:24: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 j0BCONiS072120; Tue, 11 Jan 2005 04:24:23 -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 j0BCOMUl072042 for ; Tue, 11 Jan 2005 04:24:23 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 5085 messnum 2007348 invoked from network[213.94.211.166/mail2.newbay.com]); 11 Jan 2005 12:24:26 -0000 Received: from mail2.newbay.com (HELO ?192.168.213.135?) (213.94.211.166) by mail09.svc.cra.dublin.eircom.net (qp 5085) with SMTP; 11 Jan 2005 12:24:26 -0000 Message-ID: <41E3C58C.60009@dehora.net> Date: Tue, 11 Jan 2005 12:24:44 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'Atom WG'" Subject: Re: Atom DTD? 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 Henry Story wrote: > > Is there a DTD available for the current spec? DTD's won't help (elements aren't ordered). Norm Walsh and Dave Pawson had an rnc schema up somewhere; don't know if they are still keeping in sync with the spec. cheers Bill From owner-atom-syntax@mail.imc.org Tue Jan 11 08:14: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 IAA21712 for ; Tue, 11 Jan 2005 08:14: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 j0BD3FT8012914; Tue, 11 Jan 2005 05:03: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 j0BD3FpX012912; Tue, 11 Jan 2005 05:03: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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0BD3Efb012635 for ; Tue, 11 Jan 2005 05:03:14 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so107908rnz for ; Tue, 11 Jan 2005 05:03: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=X1uHu5JNRr8GuduNZsg1t9tQhOiYpwHFIow/C7+WNasiZr83sKRpGTrznbXH/28oVgXxzn18c2/p4FVz9mfRReklOkFoM48wEowyRK/JEpkJYEylW9qLC1KcBzjgZ6cZN4gKD9L7Q7/ZMUJWgR9MJ9VqATEojXZ88AJcfdxvdDg= Received: by 10.38.19.34 with SMTP id 34mr74662rns; Tue, 11 Jan 2005 05:03:18 -0800 (PST) Received: by 10.38.179.71 with HTTP; Tue, 11 Jan 2005 05:03:18 -0800 (PST) Message-ID: <1f2ed5cd05011105036b98f46@mail.gmail.com> Date: Tue, 11 Jan 2005 14:03:18 +0100 From: Danny Ayers Reply-To: Danny Ayers To: atom-owl@googlegroups.com Subject: Re: Atom DTD? 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 Just realised I hadn't forwarded this to the list - it's only a first pass based on a sample instance (from Henry) - ]> -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Jan 11 08:42: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 IAA23681 for ; Tue, 11 Jan 2005 08:42: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 j0BDWxvP044620; Tue, 11 Jan 2005 05:33: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 j0BDWx8G044619; Tue, 11 Jan 2005 05:32:59 -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 j0BDWxen044561 for ; Tue, 11 Jan 2005 05:32:59 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so109109rnz for ; Tue, 11 Jan 2005 05:33:01 -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=PMWbhTVlK2UO44v1q81aXEWdHhTp3qk44ERSUDrLIaboV92t8hJE+TBVII4uUz+F5l3Y3oIibMYzkRYeL9PE9HYwTVSIXEhdsCNy4hGFqVfkOjjEe0yYyC3/3lAj0izkLXdGN8WlXI7247650d71lIxaanQp8kEHLC2t8mB9WdU= Received: by 10.38.19.34 with SMTP id 34mr85100rns; Tue, 11 Jan 2005 05:33:01 -0800 (PST) Received: by 10.38.179.71 with HTTP; Tue, 11 Jan 2005 05:33:01 -0800 (PST) Message-ID: <1f2ed5cd05011105333f05dc1@mail.gmail.com> Date: Tue, 11 Jan 2005 14:33:01 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Martin Duerst Subject: Re: PaceIRI Cc: Atom WG In-Reply-To: <6.0.0.20.2.20050111165014.07a77c90@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <6.0.0.20.2.20050111160057.07a79310@localhost> <6.0.0.20.2.20050111165014.07a77c90@localhost> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 11 Jan 2005 16:50:56 +0900, Martin Duerst wrote: > http://www.intertwingly.net/wiki/pie/PaceIRI I like it a lot in principle, my only concern is the dependency on an IDN library (nicely put together Pace, btw). As noted this might be a problem on small devices, but I would suspect that a proportion of big-device implementors might be tempted to skip this step (if they're anything like me, largely through ignorance of IRIs/IDNs in general). Is there any way of reducing the impact here? Any deployment experience from other application domains that can be drawn on? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Jan 11 08:57: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 IAA24319 for ; Tue, 11 Jan 2005 08:57: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 j0BDfxUV051691; Tue, 11 Jan 2005 05:41: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 j0BDfxwF051687; Tue, 11 Jan 2005 05:41: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 j0BDfsJ3051568 for ; Tue, 11 Jan 2005 05:41:54 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 4657 invoked by uid 17064); 11 Jan 2005 13:41:57 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.253.244.75]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 11 Jan 2005 13:41:57 -0000 In-Reply-To: <41E3C409.60004@internetalchemy.org> References: <200412201637.CEP57803@ms8.netsolmail.com> <8C202490-52AA-11D9-BCBC-000A95D9FA7A@bblfish.net> <1f2ed5cd04122009457048a39c@mail.gmail.com> <06C65E5B-63B5-11D9-8C94-000A95D9FA7A@bblfish.net> <41E3C409.60004@internetalchemy.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/mixed; boundary=Apple-Mail-19-442178857 Message-Id: <8DF9FB82-63D6-11D9-8C94-000A95D9FA7A@bblfish.net> Cc: "'Atom WG'" , bloged From: Henry Story Subject: Re: "Role of RSS in Science Publishing": Atom is in RDF format Date: Tue, 11 Jan 2005 14:41:54 +0100 To: atom-owl@googlegroups.com, Ian Davis X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-19-442178857 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit That is an issue I have thought long and hard about, starting with some writings 8 months ago on BlogEd mailing list [1]. I started off thinking of it as an inverse functional property. But that then makes it very difficult to distinguish the different versions of an Entry as shown in [1]. I then made the same mistake when modeling this in OWL [2] because I did not see the implications of confusing the id with the Entry. I then tried adding an EntryVersion object [3] to undo the harm. In the end I just realized that "id" is best seen as simply a functional property. It just requires one to make a little shift in your thinking. Think of the id as your constant Entry over time that just points via the 1/id relationship to all the Entry Versions out there (which the common mortals thing of as Entries). It makes sense when one gets used to it and is very powerful :-) Henry Story [1] This mail from May 2004 nicely describes the problem [2] for some reason I forgot the lesson of [1] when modelling [2] [3] I then realised my mistake and tried to work with EntryVersion object [4] And finally I realized that there was no need for such a thing if id is not inverse functional. --Apple-Mail-19-442178857 Content-Type: application/octet-stream; x-unix-mode=0644; name="Atom.owl" Content-Disposition: attachment; filename=Atom.owl Content-Transfer-Encoding: quoted-printable =0A=0A=20=20=0A=20=20=0A=20=20=20=20= see=20section=203.2=0A=20=20=0A=20= =20=0A=20=20=20=20see=20section=205.10=0A=0A=20=20=0A=20=20= =0A=20=20=20=20=0A=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=201=0A=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=0A=20=20=20=20= =0A= =20=20=20=20=0A=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=201=0A=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=0A=20=20=0A= =20=20=0A=20=20=20=20see=20section=204.=20of=20Atom=20Spec=0A[[note:=20it=20would=20be=20= more=20in=20sync=20with=20convention=20of=20class=20names=20for=20feed=20= to=20be=20capitalised=20to=20"Feed"]]=0A=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=201=0A=20=20=20=20=20=20=0A=20=20= =20=20=0A=20=20=20=20=0A=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=201=0A=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=0A=20=20=20=20= =0A= =20=20=0A=20=20=0A=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=201=0A=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=201=0A=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=201=0A=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20=20=0A=20= =20=20=20=0A=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=201=0A=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=0A=20=20=20=20= =0A= =20=20=20=20see=20section=204.2=0A=20=20=20=20=0A=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20= =20=20=20=201=0A=20=20=20=20=20=20=0A=20=20= =20=20=0A=20=20=20=20=0A=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=201=0A=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=0A=20=20=20=20=0A=20=20= =0A=20=20=0A=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=201=0A=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=0A=20=20=20=20=0A=20=20=20= =20=0A=20=20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=201=0A=20=20=20=20=20=20=0A=20=20= =20=20=0A=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=201=0A=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=201=0A=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=201=0A=20=20=20=20=20=20=0A=20= =20=20=20=0A=20=20=20=20see=20section=205=20of=20the=20Atom=20spec=0A=20=20= =0A=20=20=0A=20=20=20=20= See=20section=203.4=0A=0A=20=20=0A= =20=20=0A=20=20=20=20see=20section=204.2.9=0A=20=20=0A=20=20= =0A=20=20=20=20=0A=20=20=20=20see=20section=204.2.6=20for=20Head=0Aans=20section=205.5=20for=20= Element=0A=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=0A=20=20=20=20=0A=20=20= =0A=20=20=0A= =20=20=20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20see=20section=204.2.8=20for=20Head=0Aand=20section=205.6=20for=20= Entry=0A=20=20=20=20= =0A=20=20=0A=20=20=0A=20=20=20=20= =0A=20=20=20=20=0A=20= =20=20=20=0A=20=20=20=20= see=20section=204=0A=20=20= =0A=20=20=0A= =20=20=20=20=0A=20=20=20=20= see=20section=204.2.9=0A=20=20= =0A=20=20= =0A=20=20=20=20see=20section=20=204.2.5=20for=20Head=0Aand=20section=205.4=20for=20= Entry=0A=20=20=20=20=0A=20=20=20=20=0A=20= =20=20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20= =0A=20=20=0A=20=20=0A=20=20=20=20=0A=20=20=20=20=0A=20=20=20=20=0A=20= =20=20=20see=20section=204.2.4=0A=20=20=0A=20= =20=0A=20=20=20=20see=20section=205.3=0A=20=20=20=20=0A=20=20=20=20=0A=20= =20=20=20=0A=20=20= =0A=20=20=0A= =20=20=20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20see=20section=204.2.2=0A=20=20=20=20=0A=20=20=0A=20=20= =0A=20=20=20=20= see=20section=205.10=0A=20=20=20=20= =0A=20=20=20=20=0A=20= =20=20=20=0A=20=20= =0A=20=20= =0A=20=20=20=20=0A=20=20=20=20= =0A=20= =20=20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20see=20section=203.5.3=20for=20link=20href=0Aand=20section=203.4.1=20for=20= Service=20href=0A=20=20=0A=20=20= =0A=20=20=20=20=0A=20=20=20=20= see=20section=204.2.11=0A=0A[[=20the=20range=20of=20this=20= property=20should=20be=20a=20TEXT=20thing=20which=20sounds=20like=20a=20= union=20of=203=20different=20types=20of=20literals=20]]=0A= =20=20=20=20=0A=20=20= =0A=20=20=0A= =20=20=20=20see=20section=204.2.9=0A=0A[[=20this=20represents=20the=20software=20= agent=20string=0AI=20can't=20find=20a=20way=20to=20get=20this=20to=20= work=20out=20quite=20right.=20The=20content=20of=20this=20element=20is=20= meant=20to=20be=20the=20content=20of=20the=20agent=20]]=0A= =0A=20=20=20=20=0A=20=20=20=20= =0A=20=20= =0A=20=20=0A=20=20=20=20see=20section=204.2.10=0A=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20= =0A=20=20=0A=20=20= =0A=20=20=20=20=0A=20=20=20=20=0A=20=20=20=20= see=20section=205.12=0A=20=20= =0A=20=20=0A=20=20=20=20=0A= =20=20=20=20see=203.5.1=0A=20=20=20=20=0A=20= =20=20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20=20= =20=20=20=20=20=20=20=20=20=20related=0A=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20alternate=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20= =0A=20=20=0A=20=20= =0A=20=20=20=20see=20section=205.10.2=0A=0A[[should=20this=20be=20inverse=20= functional?=20don't=20know=20yet=20]]=0A=20=20=20=20= =0A= =20=20=20=20=0A=20=20=20=20= = =0A=20=20=0A=20=20=0A=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=0A=20=20=20=20=0A=20=20=20=20= =0A=20= =20=20=20see=20section=204.2.1=0A=0A[[=20This=20should=20point=20to=20a=20new=20= TEXT=20literal=20type,=20which=20I=20can't=20create=20easily=20in=20= Prot=C3=A9g=C3=A9,=20but=20which=20might=20be=20possible=20in=20RDF=20]]=0A= =0A[[=20There=20is=20a=20clash=20with=20title=20from=20the=20link=20= construct=20which=20can=20only=20be=20of=20type=20string=20= ]]=0A=20=20=20=20=0A=20=20= =0A=20=20=0A=20=20=20=20see=20section=204.2.12=20for=20Head=0Aand=20section=205.7=20for=20= Entry=0A=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=0A=20=20=20=20=0A=20=20=20=20= =0A=20= =20=20=20=0A=20=20= =0A=20=20=0A=20=20=20=20see=20section=205.9=20=0A[[This=20is=20a=20TEXT=20construct,=20need=20= to=20find=20the=20literal=20that=20goes=20with=20this=20= ]]=0A=20=20=20=20=0A=20=20=20=20= =0A=20=20=0A= =20=20=0A=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20see=20section=204.1for=20feed=0Aand=20section=204.2.9=20for=20= Generator=0A=20=20=20=20=0A=20=20= =0A=20=20= =0A=20=20=20=20=0A=20=20=20=20= see=20section=203.2.1=0A=0A[[it=20is=20not=20clear=20why=20= one=20should=20reduce=20the=20number=20of=20names=20a=20person=20has=20= to=20one]]=0A=20=20=20=20=0A=20=20=20=20= =0A=20=20= =0A=20=20=0A=20=20=20=20see=20section=203.5.5=0A=20=20=20=20=0A=20=20=20=20=0A=20=20=20=20= =0A=20=20= =0A=20=20=0A=20=20=20=20=0A=20=20=20=20= =0A=20=20= =20=20=0A=20=20=20=20= see=20section=204.2.7=0A=20=20= =0A=20=20=0A=20=20=20=20see=20section=203.2.3=0A=0A[[this=20definitively=20would=20be=20better=20= associated=20with=20a=20mailto:..=20uri=20and=20be=20inverse=20= functional.=20IE=20one=20should=20conclude=20that=20if=20two=20atom=20= person=20constructs=20are=20related=20to=20the=20same=20mailto=20uri,=20= thery=20are=20the=20same=20person]]=20=0A[[=20it=20also=20seems=20a=20= pitty=20to=20restrict=20the=20number=20of=20emails=20a=20person=20can=20= have=20to=20one]]=0A=20=20=20=20=0A=20=20=20=20=0A=20=20= =20=20=0A=20=20= =0A=20=20=0A=20=20=20=20=0A=20=20=20=20= see=203.5.2=20for=20Link=0Aand=205.10.1=20for=20Content.=0A=0A= [[I=20am=20not=20absolutely=20sure=20these=20are=20the=20same=20= properties,=20though=20they=20are=20very=20similar=20]]=0A= =0A=20=20=20=20=0A=20=20= =20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20= =0A=20=20=0A=20=20= =0A=20=20=20=20= =0A=20=20=20=20=0A=20=20=20= =20see=20section=204.2.3=0A=0A=20=20=20=20=0A=20=20=0A=20=20= =0A=20=20=20=20= = =0A=20=20=20=20see=20section=205.8=0A=20=20=20=20=0A=20=20=20=20=0A=20=20= =0A=20=20=0A=20=20=20=20= =0A=20=20=20=20=0A=20=20=20=20= =0A=20=20= =20=20see=20section=203.5.4=0A=20=20=0A= =20=20=0A=20=20=20=20= =0A= =20=20=20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20see=20section=203.2.2=20for=20Person=0Aand=20section=204.2.9=20for=20= Generator=0A=0A[[=20note=20that=20it=20may=20be=20much=20more=20= interesting=20to=20associate=20an=20inverse=20funtional=20uri=20with=20a=20= person.=20This=20means=20that=20the=20person=20is=20identified=20exactly=20= by=20that=20uri.=20One=20can=20then=20use=20the=20URI=20to=20find=20= other=20information=20on=20the=20web=20corresponding=20to=20that=20uri.=20= But=20then=20perhaps=20it=20would=20be=20better=20if=20uri=20were=20= defined=20a=20little=20more=20presicely]]=0A=20=20=20=20= =0A=20=20= =0A=0A=0A=0A= --Apple-Mail-19-442178857 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 11 Jan 2005, at 13:18, Ian Davis wrote: > > Henry, > > I don't think this is correct. id _should_ be an IFP - it's the unique > identifier for the element after all. I think you should relax any > constraint on published having cardinality of 1. The same entry can be > published multiple times. > > Ian > > > > > On 11/01/2005 09:41, Henry Story wrote: >> Just found this mail and thought it worth replying to. It points out >> a little bug >> with the Ontology I just released lately. I made the entry id inverse >> functional. >> That won't do. >> If id is inverse functional, then given two entries with the same id >> _f1----a-----> >> |---entry--> _e1 ---a-----> >> | |-----id----> >> | |---title---> "first verzion of the entry" >> | |-published-> "20 Dec 2004" >> |... >> _f1----a-----> >> |---entry--> _e2 ---a-----> >> | |-----id----> >> | |---title---> "second version of the entry" >> | |-published-> "10 Jan 2005" >> |... >> One would have to conclude that the anonymous nodes _e1 and _e2 were >> the same. >> Ie >> -----1/id-------> _e >> the inverse of id (called 1/id) can only have one value. >> But if we tried to do this we would have to conclude that the entry >> with >> , called _e had two publication dates. >> Yet an >> Entry can only have at most one. >> So we end up with a contradiction by making id inverse functional. >> By simply making it functional we bypass that problem, and we have >> correctly >> model what we had: namely we have two Entries with the same id, which >> one can >> think of as two versions of the same entry. >> On 20 Dec 2004, at 18:45, Danny Ayers wrote: >>> ... >>> Some of the possible approaches for an RDF/XML expression of the info >>> include (ignoring namespace decls & case!): >>> >>> RSS 1.0 style: >>> >>> >>> >>> ... >>> >>> Stuff >>> ... >>> >>> ... >>> >> this would be equivalent to making id inverse functional. If you do >> this >> then you have the merging problem explained above. >>> >>> ------------------------------------- >>> >>> A bit more plain-XMLy : >>> >>> >>> >>> ... >>> >>> >>> Stuff >>> ... >>> >>> ... >>> >>> ... >>> >> yes this just groups the entries in an "entries" tag. I don't see >> that it >> adds much. (I know you are just pointing out all the different ways >> one can >> do this) >>> >>> ---------------------------- >>> >>> Lumpier: >>> >>> >>> ... >>> >>> >>> Stuff >>> >>> >>> ... >>> >> note: the RDF people think that having properties named >> hasXXX is quaint. Or so at least DanC told me on #irc quite a >> few months ago. >>> ------------------------------ >>> >>> Closer to Atom 0.3 : >>> >>> >>> ... >>> >>> vemmi://example.org/2003/32397 >>> Stuff >>> ... >>> >>> ... >>> >> This is exactly right, except that id should absolutely not be >> inverse functional. >> Just functional will do :-) >>> >>> The last is kind of interesting, having the id attached to a blank >>> node. If id were spec'ed as an inverse functional property that might >>> work nicely. >>> >>> But as far as I can tell none fit too well with : >>> >>> >>> >>> Cheers, >>> Danny. >>> >>> -- >>> >>> http://dannyayers.com >>> > --Apple-Mail-19-442178857-- From owner-atom-syntax@mail.imc.org Tue Jan 11 09:15: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 JAA25706 for ; Tue, 11 Jan 2005 09:15: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 j0BE6CEY076929; Tue, 11 Jan 2005 06:06: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 j0BE6C3N076928; Tue, 11 Jan 2005 06:06:12 -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 j0BE6AJE076904 for ; Tue, 11 Jan 2005 06:06:11 -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 <0IA5009W7O9TCC10@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Tue, 11 Jan 2005 15:01:05 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IA5000YHO4FDVP0@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Tue, 11 Jan 2005 14:57:52 +0100 (CET) Date: Tue, 11 Jan 2005 14:59:47 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: PaceIRI In-reply-to: <6.0.0.20.2.20050111160057.07a79310@localhost> To: Martin Duerst 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: <6.0.0.20.2.20050111160057.07a79310@localhost> 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 Tue, 11 Jan 2005 16:04:16 +0900, Martin Duerst wrote: > I have completed (as far as I'm concerned) PaceIRI. Looks good, but I dislike this point: «Do *not* replace element/attribute names that read 'uri'. This will lead to somewhat strange sentences as "The content of atom:uri in a Person construct MUST be a IRI." While this makes the spec somewhat strange to read in very few places, it will work out for users.» I think all the 'uri' elements and attributes should jump on the next train to '/dev/null' and be replaced with 'href', ordinary Link Constructs or whatever. They stick out from the specification like dobermans in a duck-pond and just feels awkward and «not right». With the introduction of IRI's, I think they are even more misplaced and there's better reasons for us to remove them completely. -- 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 Tue Jan 11 09:40: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 JAA27402 for ; Tue, 11 Jan 2005 09:40: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 j0BER35k098856; Tue, 11 Jan 2005 06: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 j0BER3d2098855; Tue, 11 Jan 2005 06:27:03 -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 j0BER3RM098820 for ; Tue, 11 Jan 2005 06:27:03 -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 2CB504F0AB; Tue, 11 Jan 2005 09:27:11 -0500 (EST) Message-Id: <6.0.0.20.2.20050111231842.07243550@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 11 Jan 2005 23:23:25 +0900 To: Danny Ayers From: Martin Duerst Subject: Re: PaceIRI Cc: Atom WG In-Reply-To: <1f2ed5cd05011105333f05dc1@mail.gmail.com> References: <6.0.0.20.2.20050111160057.07a79310@localhost> <6.0.0.20.2.20050111165014.07a77c90@localhost> <1f2ed5cd05011105333f05dc1@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 22:33 05/01/11, Danny Ayers wrote: > >On Tue, 11 Jan 2005 16:50:56 +0900, Martin Duerst wrote: > >> http://www.intertwingly.net/wiki/pie/PaceIRI > >I like it a lot in principle, my only concern is the dependency on an >IDN library (nicely put together Pace, btw). Thanks! >As noted this might be a >problem on small devices, but I would suspect that a proportion of >big-device implementors might be tempted to skip this step (if they're >anything like me, largely through ignorance of IRIs/IDNs in general). >Is there any way of reducing the impact here? Any deployment >experience from other application domains that can be drawn on? An IDN library consists of two parts: Nameprep, which is the part needing the big tables, and punycode encoding, which is the encoding/ compression algorithm that is quite compact. My understanding is that indeed some implementers are taking shortcuts with nameprep, although they are definitely not supposed to do so according to the specs. (One possibility where this would be possible even while strictly conforming is for IRIs directly input on a mobile device, where the manufacturer knows what characters can be input and can guarantee that these don't cause problems with nameprep.) Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Jan 11 09:40: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 JAA27420 for ; Tue, 11 Jan 2005 09:40: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 j0BER67N098992; Tue, 11 Jan 2005 06:27: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 j0BER6q8098991; Tue, 11 Jan 2005 06:27:06 -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 j0BER60Q098963 for ; Tue, 11 Jan 2005 06:27:06 -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 B199F4F168; Tue, 11 Jan 2005 09:27:14 -0500 (EST) Message-Id: <6.0.0.20.2.20050111232401.0703db00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 11 Jan 2005 23:25:57 +0900 To: Asbj=?ISO-2022-JP?B?GyRCj1MbKEI=?=n Ulsberg From: Martin Duerst Subject: Re: PaceIRI Cc: Atom-Syntax In-Reply-To: References: <6.0.0.20.2.20050111160057.07a79310@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; 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 I'm fine either way on attribute naming, but would like to point out that this is an issue orthogonal to PaceIRI. The main point I was making was that I was saying that changing the attribute names from 'uri' to 'iri' isn't necessary. But I would also be fine with a to change to 'iri' if that turned out to be the consensus on this list. In summary, PaceIRI is about functionality, not about attribute names. Regards, Martin. At 22:59 05/01/11, Asbj$BS(Bn Ulsberg wrote: >On Tue, 11 Jan 2005 16:04:16 +0900, Martin Duerst wrote: > >> I have completed (as far as I'm concerned) PaceIRI. > >Looks good, but I dislike this point: > > $B%)(BDo *not* replace element/attribute names that read 'uri'. This will > lead to somewhat strange sentences as "The content of atom:uri in > a Person construct MUST be a IRI." While this makes the spec somewhat > strange to read in very few places, it will work out for users.$B%5(B > >I think all the 'uri' elements and attributes should jump on the next >train to '/dev/null' and be replaced with 'href', ordinary Link Constructs >or whatever. They stick out from the specification like dobermans in a >duck-pond and just feels awkward and $B%)(Bnot right$B%5(B. > >With the introduction of IRI's, I think they are even more misplaced and >there's better reasons for us to remove them completely. > >-- >Asbj$BS(Bn Ulsberg -=|=- http://virtuelvis.com/quark/ >$B%)(BHe's a loathsome offensive brute, yet I can't look away$B%5(B > From owner-atom-syntax@mail.imc.org Tue Jan 11 09:51: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 JAA28022 for ; Tue, 11 Jan 2005 09: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 j0BEehjx012499; Tue, 11 Jan 2005 06:40: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 j0BEehZn012498; Tue, 11 Jan 2005 06:40:43 -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 j0BEegRR012453 for ; Tue, 11 Jan 2005 06:40:43 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.110] (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 j0BEeoCh018875 for ; Tue, 11 Jan 2005 09:40:50 -0500 (EST) Message-ID: <41E3E56F.1030209@intertwingly.net> Date: Tue, 11 Jan 2005 09:40:47 -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: New AtomPubIssuesList for 2004/12/11 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> In-Reply-To: <41AF672A.60106@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 The biggest open issue (at least on the format side, and potentially on the protocol side) is extensibility. I would like to see us get *something* into the drafts; even if imperfect, it can be incrementally improved upon. So, I'm scheduling all the open extensibility and versioning paces for dicussion: PaceAltExtensibilityAndVersioning PaceExtendingAtom PaceExtensibilityAndVersioning PaceExtensibilityAndVersioningNoScenarios PaceExtensionNamespace PaceMinimalEntryVersioning PaceMustUnderstandElement PacePropertyDesign PaceSupersede - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Jan 11 11:07: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 LAA04163 for ; Tue, 11 Jan 2005 11:07: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 j0BFsqgY070233; Tue, 11 Jan 2005 07:54: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 j0BFsqnq070232; Tue, 11 Jan 2005 07:54:52 -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 j0BFspfm070223 for ; Tue, 11 Jan 2005 07:54:52 -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 j0BFswe7020192 for ; Tue, 11 Jan 2005 08:55:00 -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 <0IA500E01T7QOD@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Tue, 11 Jan 2005 10:52:06 -0500 (EST) Received: from localhost (vpn-129-150-34-223.Central.Sun.COM [129.150.34.223]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IA5006BMTEJH5@bur-mail1.east.sun.com> for atom-syntax@imc.org; Tue, 11 Jan 2005 10:52:06 -0500 (EST) Received: from ndw by localhost with local (Exim 4.34) id 1CoOIz-0004ip-Tj for atom-syntax@imc.org; Tue, 11 Jan 2005 10:51:37 -0500 X-URL: http://nwalsh.com/ Date: Tue, 11 Jan 2005 10:51:35 -0500 From: Norman Walsh Subject: Re: Atom DTD? In-reply-to: <41E3C58C.60009@dehora.net> To: Atom Syntax Message-id: <87fz189d6g.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: <41E3C58C.60009@dehora.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 / Bill de h=C3=93ra was heard to say: | Henry Story wrote: |> Is there a DTD available for the current spec? | | DTD's won't help (elements aren't ordered). Norm Walsh and Dave Pawson | had an rnc schema up somewhere; don't know if they are still keeping | in sync with the spec. I plan to sync it when the next Atom ID comes out. Be seeing you, norm =2D-=20 Norman Walsh | It is as easy for the strong man to be http://nwalsh.com/ | strong, as it is for the weak to be | weak.-- Emerson --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBB4/YHOyltUcwYWjsRAlgWAKCNK6JXFEszW06EX7KfY8ZjNWzXLgCgmdBS q2sdj7k8eAAp86QYzgiot2k= =1Au2 -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Tue Jan 11 15:51: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 PAA26301 for ; Tue, 11 Jan 2005 15:51: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 j0BKXJ6R008250; Tue, 11 Jan 2005 12:33: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 j0BKXJ4I008249; Tue, 11 Jan 2005 12:33:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0BKXIP6008240 for ; Tue, 11 Jan 2005 12:33:18 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24193; Tue, 11 Jan 2005 15:33:28 -0500 (EST) Message-Id: <200501112033.PAA24193@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: atom-syntax@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atompub-format-04.txt Date: Tue, 11 Jan 2005 15:33:28 -0500 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF. Title : The Atom Syndication Format Author(s) : M. Nottingham, R. Sayre Filename : draft-ietf-atompub-format-04.txt Pages : 36 Date : 2005-1-11 This document specifies Atom, an XML-based Web content and metadata syndication format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-atompub-format-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-atompub-format-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-11160439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atompub-format-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atompub-format-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-11160439.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-atom-syntax@mail.imc.org Tue Jan 11 16:15: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 QAA00976 for ; Tue, 11 Jan 2005 16:15: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 j0BKwf39025954; Tue, 11 Jan 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 j0BKwfJM025953; Tue, 11 Jan 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 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 j0BKweir025873 for ; Tue, 11 Jan 2005 12:58: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 1CoT5p-0000jq-BW for atom-syntax@imc.org; Tue, 11 Jan 2005 20:58:21 +0000 Message-ID: <41E43E05.7050009@franklinmint.fm> Date: Tue, 11 Jan 2005 15:58:45 -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: format-04 HTML, diffs 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.atompub.org/2005/01/10/draft-ietf-atompub-format-04-from-3.diff.html http://www.atompub.org/2005/01/10/draft-ietf-atompub-format-04.html There are some editorial issues brought up on-list recently that aren't addressed here. I wanted to get the draft out so folks facing deadlines could work against it. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Jan 11 16:38: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 QAA06345 for ; Tue, 11 Jan 2005 16:38: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 j0BLS85N043251; Tue, 11 Jan 2005 13:28: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 j0BLS8wp043250; Tue, 11 Jan 2005 13:28:08 -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 j0BLS7p7043164 for ; Tue, 11 Jan 2005 13:28:07 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.110] (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 j0BLSC4R025517 for ; Tue, 11 Jan 2005 16:28:13 -0500 (EST) Message-ID: <41E444EB.6030903@intertwingly.net> Date: Tue, 11 Jan 2005 16:28:11 -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@imc.org Subject: New AtomPubIssuesList for 2005/01/11 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> In-Reply-To: <41E3E56F.1030209@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 [Reissuing with a corrected subject line] Sam Ruby wrote: > > The biggest open issue (at least on the format side, and potentially on > the protocol side) is extensibility. I would like to see us get > *something* into the drafts; even if imperfect, it can be incrementally > improved upon. > > So, I'm scheduling all the open extensibility and versioning paces for > dicussion: > > PaceAltExtensibilityAndVersioning > PaceExtendingAtom > PaceExtensibilityAndVersioning > PaceExtensibilityAndVersioningNoScenarios > PaceExtensionNamespace > PaceMinimalEntryVersioning > PaceMustUnderstandElement > PacePropertyDesign > PaceSupersede > > - Sam Ruby > From owner-atom-syntax@mail.imc.org Tue Jan 11 20:24: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 UAA23806 for ; Tue, 11 Jan 2005 20:24: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 j0C18Ut1095726; Tue, 11 Jan 2005 17:08: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 j0C18UFf095725; Tue, 11 Jan 2005 17:08:30 -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 j0C18SPU095696 for ; Tue, 11 Jan 2005 17:08:28 -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 j0C17FRi028683; Wed, 12 Jan 2005 01:07:26 GMT In-Reply-To: <41E43E05.7050009@franklinmint.fm> References: <41E43E05.7050009@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-15-483301198; protocol="application/pkcs7-signature" Message-Id: <4CCDD8E0-6436-11D9-B651-000A95DC3D90@mac.com> Cc: Atom-Syntax From: Graham Subject: Re: format-04 HTML, diffs Date: Wed, 12 Jan 2005 01:07:15 +0000 To: Robert Sayre X-Mailer: Apple Mail (2.619) 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-15-483301198 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit This sentence took me a long time to figure out its intended meaning: "Escaped markup is interpreted as a text representation of markup, and MUST NOT be interpreted as markup itself." By "Escaped markup" don't you just mean "text"? Or "text containing characters sometimes used for markup"? Currently the phrasing boils down to "Stuff that is markup isn't markup". Similarly: "The HTML markup must be escaped; for example, "
" as "<br>". The HTML markup SHOULD be such that it example, "
" as "<br>"." is mixing layers quite a bit. "The HTML markup must appear as text [in the infoset], such that it appears escaped in the XML source". Graham --Apple-Mail-15-483301198 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 9w0BCQUxDxcNMDUwMTEyMDEwNzE2WjAjBgkqhkiG9w0BCQQxFgQUdClMQ4JlIjq5MF3cXr9XYuBy 6kIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAPaaXa34oWZTjnn+FyMmlZYDj ztMrVQFGBPDwM6hM2Ui/Agle2+dX0yPCaBuhSu6jAMlA5P2+kz9jQSERs6fWmgYeCjgkE3W8k0xz C/2+nM7hCzpE3Vk2Dd4QUH+dM1+7BB3GqUJnBFPl9EslYJjI1hizhdHgWH50R++h5ohdt8FtJ721 PtFgnFZhlCceOn9gPr+5pT1HKwxuX8Dm6Wd+WlvMI17tx+8w8UpCuNJP8kFRwBgWHMeO1hdWf+PV oJRRYQqB1DJBm23FOoDiME8GpMbWVtWru3QycOcKFj5c5w7/WN3ml3gJIYQh2kAXZTK93wC1ox+o ve11wAethzVWZQAAAAAAAA== --Apple-Mail-15-483301198-- From owner-atom-syntax@mail.imc.org Tue Jan 11 21:20: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 VAA27809 for ; Tue, 11 Jan 2005 21:20: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 j0C28VDq005088; Tue, 11 Jan 2005 18:08: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 j0C28VwX005087; Tue, 11 Jan 2005 18:08: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 j0C28UNP005080 for ; Tue, 11 Jan 2005 18:08: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 j0C28iVu011383 for ; Tue, 11 Jan 2005 19:08:44 -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 <0IA600FQXLYJOU@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 11 Jan 2005 19:08:44 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA6007H0LYJOP@mail.sun.net> for atom-syntax@imc.org; Tue, 11 Jan 2005 19:08:43 -0700 (MST) Date: Tue, 11 Jan 2005 18:08:48 -0800 From: Tim Bray Subject: Re: format-04 HTML, diffs In-reply-to: <4CCDD8E0-6436-11D9-B651-000A95DC3D90@mac.com> To: Graham Cc: Robert Sayre , 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: <41E43E05.7050009@franklinmint.fm> <4CCDD8E0-6436-11D9-B651-000A95DC3D90@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 11, 2005, at 5:07 PM, Graham wrote: > is mixing layers quite a bit. "The HTML markup must appear as text [in > the infoset], such that it appears escaped in the XML source". Good idea I think... rather than the current convolutions around escaping and levels, talk about what ends up in the infoset. Ought to be clearer and more accurate. -Tim From owner-atom-syntax@mail.imc.org Wed Jan 12 05: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 FAA28280 for ; Wed, 12 Jan 2005 05: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 j0C9nAkv069242; Wed, 12 Jan 2005 01:49: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 j0C9n941069241; Wed, 12 Jan 2005 01:49:09 -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 j0C9n8XL069187 for ; Wed, 12 Jan 2005 01:49:09 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 72476 messnum 6489252 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 12 Jan 2005 09:49:03 -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 72476) with SMTP; 12 Jan 2005 09:49:03 -0000 Message-ID: <41E4F2A0.2050904@dehora.net> Date: Wed, 12 Jan 2005 09:49:20 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: Re: format-04 HTML, diffs References: <41E43E05.7050009@franklinmint.fm> <4CCDD8E0-6436-11D9-B651-000A95DC3D90@mac.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 Tim Bray wrote: > > On Jan 11, 2005, at 5:07 PM, Graham wrote: > >> is mixing layers quite a bit. "The HTML markup must appear as text [in >> the infoset], such that it appears escaped in the XML source". > > > Good idea I think... rather than the current convolutions around > escaping and levels, talk about what ends up in the infoset. Ought to > be clearer and more accurate. -Tim I prefer Robert's approach - it tells me what I need to do rather than offer definitions. I suggest these variations: "Escaped markup MUST be treated as text and not interpreted as markup." "HTML markup MUST be escaped so it appears as text (pcdata) within Atom XML. For example
needs to be converted to <br/>"* To elaborate: 1. I thought we agreed to specify the format in syntactic terms. 2. Specifying in terms of the Infoset doesn't help guide me in terms of what I actually need to do to drill HTML through Atom. cheers Bill * I'm not overly fond of the short cut escaping style - <br/>; From owner-atom-syntax@mail.imc.org Wed Jan 12 07:44: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 HAA07490 for ; Wed, 12 Jan 2005 07:44: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 j0CCWUmW015373; Wed, 12 Jan 2005 04:32: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 j0CCWU9q015371; Wed, 12 Jan 2005 04:32:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxsf04.cluster1.charter.net (mxsf04.cluster1.charter.net [209.225.28.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0CCWTGg015263 for ; Wed, 12 Jan 2005 04:32:30 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from mxip18.cluster1.charter.net (mxip18a.cluster1.charter.net [209.225.28.148]) by mxsf04.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id j0CCWNY6021151 for ; Wed, 12 Jan 2005 07:32:23 -0500 Received: from cpe-68-112-239-32.ma.charter.com (HELO localhost) (68.112.239.32) by mxip18.cluster1.charter.net with ESMTP; 12 Jan 2005 07:32:23 -0500 X-Ironport-AV: i="3.88,118,1102309200"; d="scan'208"; a="697333391:sNHT15467352" Received: from ndw by localhost with local (Exim 4.34) id 1CohfV-00028A-VC for atom-syntax@imc.org; Wed, 12 Jan 2005 07:32:09 -0500 To: Atom Syntax Subject: Questions about -04 From: Norman Walsh X-URL: http://nwalsh.com/ Date: Wed, 12 Jan 2005 07:32:02 -0500 Message-ID: <873bx6x1z1.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 1. Is xml:base processing applied to the schema attribute of a Category Construct? 2. Why MUST a feed point to an alternate version. What if the feed is all I publish? 3. 4.2.2 says atom:head elements MUST NOT contain more than one atom:link element with a rel attribute value of "alternate" that has the same type attribute value. What if the atom:link elments have different hreflang values? 4. 5.14 says If an atom:entry is copied into one feed from another feed, then the atom:head element of the source feed SHOULD be inserted into the atom:entry unless the entry, as copied, already contains an atom:head... This suggests that atom:head is sometimes a child of atom:entry, but that doesn't seem to be allowed. Did I miss something? Or is it supposed to say that the contents of the head are copied into the entry? 5. 7.1 says Processing [W3C.REC-xmldsig-core-20020212]. Other XML signature mechanisms MUST NOT be used on the document element of an Atom document. Are we sure we want to prohibit them? How about making this a SHOULD and pointing out that processors are not required to recognize any mechanisms except XML DSig? Other mechanisms will be developed. Some of them may become widely deployed. Do we really want to force authors to generate non-conformant feeds when they decide to use them? I feel the same way about XML 1.1, fwiw, but I expect I'd lose that fight, so I'll just mention it in passing. Be seeing you, norm =2D-=20 Norman Walsh | It is as easy for the strong man to be http://nwalsh.com/ | strong, as it is for the weak to be | weak.-- Emerson --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBB5RjEOyltUcwYWjsRAmN7AJ9GHUC7TnrG/INjJIS7XhxZBmemlwCglTpu NCqxcs7ABkC2vdIMJzwAuCM= =52Eu -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Wed Jan 12 07:53: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 HAA08058 for ; Wed, 12 Jan 2005 07:53: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 j0CCkPZp035988; Wed, 12 Jan 2005 04:46: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 j0CCkPU2035987; Wed, 12 Jan 2005 04:46:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxsf12.cluster1.charter.net (mxsf12.cluster1.charter.net [209.225.28.212]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0CCkOTY035763 for ; Wed, 12 Jan 2005 04:46:25 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from mxip13.cluster1.charter.net (mxip13a.cluster1.charter.net [209.225.28.143]) by mxsf12.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id j0CCkKRZ020735 for ; Wed, 12 Jan 2005 07:46:20 -0500 Received: from cpe-68-112-239-32.ma.charter.com (HELO localhost) (68.112.239.32) by mxip13.cluster1.charter.net with ESMTP; 12 Jan 2005 07:46:19 -0500 X-Ironport-AV: i="3.88,118,1102309200"; d="scan'208"; a="704833234:sNHT17544468" Received: from ndw by localhost with local (Exim 4.34) id 1Cohsr-0002Cy-0S; Wed, 12 Jan 2005 07:45:57 -0500 To: mnot@pobox.com CC: Atom Syntax Subject: Editorial suggestions for Atom -04 From: Norman Walsh X-URL: http://nwalsh.com/ Date: Wed, 12 Jan 2005 07:45:56 -0500 Message-ID: <87vfa2vmrf.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 | 1. Introduction |=20 | Atom is an XML-based document format intended to allow lists of s/intended to allow/which describes/ | related information, known as "feeds". Feeds are composed of a s/, known/ known/ | [[ more motivation / design principles ]] Recent mail on the list suggests we're closing in on our end game. If these sections aren't going to get written, maybe it's time to drop the place holders from the spec? | Any element in an Atom Document MAY have an xml:base attribute. XML | Base [W3C.REC-xmlbase-20010627] processing MUST be applied to any | relative reference [RFC2396bis] present in an Atom Document. This s/relative reference/relative URI reference/ | includes such elements and attributes as specified by Atom itself, as | well as those specified by extensions to Atom. |=20 | Any element in an Atom Document MAY have an xml:lang attribute, whose | content indicates the default natural language of the element's s/default // | 3. Common Atom Constructs |=20 | Many of Atom's elements share a few common structures. This section | defines a few such structures and their requirements, for convenient s/, / / | 3.2 Person Constructs |=20 | A Person construct is an element that describes a person, | corporation, or similar entity. |=20 | Person constructs MAY be extended by namespace-qualified element | children. |=20 | This specification assigns no significance to the order of appearance | of the child elements of a Person construct. s/of a Person/in a Person/ | 3.4 Service Constructs |=20 | A Service construct is an empty element that conveys the URI of an | Atom Publishing Protocol [Atom-protocol] service associated with an | entry or feed. The type of service is identified by the element name. s/element name/element's name attribute/ |=20 | A Service construct has the following attribute: But then the name attribute isn't described. | 3.4.1 "href" Attribute |=20 | The "href" attribute contains the a URI pointing to the endpoint of | the service named by the name attribute. atom:service elements MUST But then it's mentioned here. So maybe I'm confused. | have a "href" attribute, whose value MUST be a URI reference | [RFC2396bis]. |=20 | xml:base processing MUST be applied to the "href" attribute. |=20 | 3.5 Link Constructs |=20 | A Link construct is an empty element that describes a connection from s/describes a connection/defines a reference/ | an Atom Document to another Web resource. |=20 | 3.5.1 "rel" Attribute |=20 | Link constructs MAY have an optional "rel" attribute that indicates s/an optional// | the link relation type. If the "rel" attribute is not present, the | link construct MUST be interpreted as if the link relation type is | "alternate". |=20 | rel_attribute =3D segment-nz-nc / URI |=20 | The value of "rel" MUST be either a name, which is non-empty and does | not contain any colon (":") characters, or a URI [RFC2396bis]. Note | that use of a relative reference to the "rel" value URI is not s/reference to the "rel" value URI/URI in the "rel" attribute/ | The value "related" signifies that the URI in the value of the href | attribute identifies a resource to which the resource described by s/to which/related to/ | the containing atom:feed or atom:entry element is related. For s/is related.// | 3.5.2 "type" Attribute |=20 | Link constructs MAY have a type attribute, whose value MUST conform | to the syntax of a MIME media type [RFC2045]. |=20 | The type attribute's value is an advisory media type; it MAY be used | as a hint to determine the type of the representation which is Suggest: The type attribute's value is an advisory media type; it is a hint about the type of the representation which is | expected to be returned when the value of the href attribute is | dereferenced. Note that the type attribute does not override the | actual media type returned with the representation. | 3.5.6 "length" Attribute |=20 | The "length" attribute indicates an advisory length of the linked | content in octets; it MAY be used as a hint to determine the content | length of the representation returned when the URI in the href Similarly: The "length" attribute indicates an advisory length of the linked content in octets; it is a hint about the content length of the representation returned when the URI in the href | attribute is dereferenced. Note that the length attribute does not | override the actual content length of the representation as reported | by the underlying protocol. | 3.6 Identity Constructs |=20 | An Identity construct is an element whose content conveys a | permanent, universally unique identifier for the construct's parent. | Its content MUST be a URI, as defined by [RFC2396bis]. Note that the | definition of "URI" excludes relative references. Replace the last sentence with "It may not be a relative URI." | 3.7.1 The "term" Attribute |=20 | The "term" attribute will be a string which identifies the category s/will be a/is/ | within the categorization scheme to which the entry or feed belongs. s/within the categorization scheme// | 4.2.12 "atom:info" Element |=20 | The "atom:info" element is a Text construct that conveys a | human-readable explanation of the feed format itself. atom:head | elements MAY contain an atom:info element, but MUST NOT contain more | than one. |=20 | The atom:info element SHOULD NOT considered meaningful by processors; | it is a convenience to publishers in certain situations. s/ in certain situations// | 5.12.2 "src" attribute |=20 | atom:content MAY have a "src" attribute, whose value MUST be a URI | reference [RFC2396bis]. If the "src" attribute is present, software | MAY use the URI to retrieve the content. If the "src" attribute is | present, atom:content MUST be empty. That is to say, the content may | be retrievable using "src=3D" URI, or it may be contained within | atom:content, but not both. |=20 | If the "src" attribute is present, the "type" attribute SHOULD be | provided and MUST be a MIME media type [RFC2045], rather than "TEXT", | "HTML", or "XHTML". The value is advisory; that is to say, upon | dereferencing the URI to retrieve the content, if the server | providing that content also provides a media type, the | server-provided media type is authoritative. |=20 | If the value of type begins with "text/" or ends with "+xml", the | content SHOULD be local; that is to say, no "src" attribute should be | provided. The last paragraph here seems oddly placed in the section about the src attribute. I suggest moving it up to 5.12. | 5.12.3 Processing Model |=20 | Software MUST apply the following rules in succession in the order s/in succession // | 6. For all other values of "type", the content of atom:content MUST | be a valid Base64 encoding [RFC3548], which when decoded SHOULD | be suitable for handling by software that knows the indicated | media type. In this case, the characters in the Base64 encoding | may be preceded and followed in the atom:content element by | whitespace, and lines are separated by a single newline (U+000A) | character, as required by XML. s/required by XML/required by XML Schema/ I think. XML doesn't say anything about Base64 encoded content. Be seeing you, norm =2D-=20 Norman Walsh | Everything has been said before, but http://nwalsh.com/ | since nobody every listens we have to | keep going back and beginning all over | again.--Andr=C3=A9 Gide --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBB5RwEOyltUcwYWjsRAsJbAJ9NuI+r6mWcp6ebQsqaMj/5/hmWNACdGKhC GE8bzVZJzOH9C0VsHR+gimU= =jsjU -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Wed Jan 12 08:27: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 IAA11452 for ; Wed, 12 Jan 2005 08:27: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 j0CDHkQ8085623; Wed, 12 Jan 2005 05:17: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 j0CDHkfl085622; Wed, 12 Jan 2005 05:17:46 -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 j0CDHe5E085438 for ; Wed, 12 Jan 2005 05:17:41 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 12 Jan 2005 13:17:36 -0000 Received: from p50824617.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.70.23) by mail.gmx.net (mp009) with SMTP; 12 Jan 2005 14:17:36 +0100 X-Authenticated: #1915285 Message-ID: <41E5236C.3040709@gmx.de> Date: Wed, 12 Jan 2005 14:17:32 +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: mnot@pobox.com, Atom Syntax Subject: Re: Editorial suggestions for Atom -04 References: <87vfa2vmrf.fsf@nwalsh.com> In-Reply-To: <87vfa2vmrf.fsf@nwalsh.com> 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: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Norman Walsh wrote: > ... > | Any element in an Atom Document MAY have an xml:base attribute. XML > | Base [W3C.REC-xmlbase-20010627] processing MUST be applied to any > | relative reference [RFC2396bis] present in an Atom Document. This > > s/relative reference/relative URI reference/ "Relative reference" is the correct terminology used in RFC2396bis. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Wed Jan 12 08: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 IAA13801 for ; Wed, 12 Jan 2005 08:52: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 j0CDf6I7013943; Wed, 12 Jan 2005 05:41: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 j0CDf50E013942; Wed, 12 Jan 2005 05:41:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxsf09.cluster1.charter.net (mxsf09.cluster1.charter.net [209.225.28.209]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0CDf5Mb013890 for ; Wed, 12 Jan 2005 05:41:05 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from mxip15.cluster1.charter.net (mxip15a.cluster1.charter.net [209.225.28.145]) by mxsf09.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id j0CDf1CE030034 for ; Wed, 12 Jan 2005 08:41:01 -0500 Received: from cpe-68-112-239-32.ma.charter.com (HELO localhost) (68.112.239.32) by mxip15.cluster1.charter.net with ESMTP; 12 Jan 2005 08:40:57 -0500 X-Ironport-AV: i="3.88,118,1102309200"; d="scan'208"; a="693045344:sNHT21741052" Received: from ndw by localhost with local (Exim 4.34) id 1Coijs-00051d-Nv for atom-syntax@imc.org; Wed, 12 Jan 2005 08:40:44 -0500 To: Atom Syntax Subject: Re: Questions about -04 References: <873bx6x1z1.fsf@nwalsh.com> From: Norman Walsh X-URL: http://nwalsh.com/ Date: Wed, 12 Jan 2005 08:40:44 -0500 In-Reply-To: <873bx6x1z1.fsf@nwalsh.com> (Norman Walsh's message of "Wed, 12 Jan 2005 07:32:02 -0500") Message-ID: <871xcqlq8z.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 / Norman Walsh was heard to say: | 4. 5.14 says | | If an atom:entry is copied into one feed from another feed, then the | atom:head element of the source feed SHOULD be inserted into the | atom:entry unless the entry, as copied, already contains an atom:head.= .. | | This suggests that atom:head is sometimes a child of atom:entry, | but that doesn't seem to be allowed. Did I miss something? | Or is it supposed to say that the contents of the head are | copied into the entry? Nevermind. I missed the title of 5.14, I guess. Be seeing you, norm =2D-=20 Norman Walsh | Everything should be made as simple as http://nwalsh.com/ | possible, but no simpler. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBB5SjcOyltUcwYWjsRAl9KAJwNFWvXvkCVXXmCd61jaN/wlzM9RACghUwL t23CDlJJaAP5QPaLyzYBJFI= =CQYT -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Wed Jan 12 12:13: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 MAA29457 for ; Wed, 12 Jan 2005 12:13: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 j0CGvrV8079576; Wed, 12 Jan 2005 08:57: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 j0CGvrGR079574; Wed, 12 Jan 2005 08:57: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 j0CGvlu6079520 for ; Wed, 12 Jan 2005 08:57: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 1Colo6-0008A9-3C; Wed, 12 Jan 2005 16:57:18 +0000 Message-ID: <41E55708.5060804@franklinmint.fm> Date: Wed, 12 Jan 2005 11:57:44 -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: Questions about -04 References: <873bx6x1z1.fsf@nwalsh.com> In-Reply-To: <873bx6x1z1.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: >1. Is xml:base processing applied to the schema attribute of a Category > Construct? > > It's a URI, rather a URI reference. From 2396bis: "URI-reference = URI / relative-ref" I guess this means we should put the "no relative references" language here as well. >2. Why MUST a feed point to an alternate version. What if the feed is all > I publish? > > I don't know. I say we drop it. >3. 4.2.2 says > > atom:head elements MUST NOT contain more than one atom:link element > with a rel attribute value of "alternate" that has the same type > attribute value. > > What if the atom:link elments have different hreflang values? > > Or, for that matter, different titles and URIs. I think we should drop the restriction. >5. 7.1 says > > Processing [W3C.REC-xmldsig-core-20020212]. Other XML signature > mechanisms MUST NOT be used on the document element of an Atom > document. > > Are we sure we want to prohibit them? > > I think we should drop that sentence. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Jan 12 12:46: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 MAA01453 for ; Wed, 12 Jan 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 j0CHapMZ006651; Wed, 12 Jan 2005 09:36: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 j0CHapL7006650; Wed, 12 Jan 2005 09:36: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-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 j0CHaoAs006644 for ; Wed, 12 Jan 2005 09:36:50 -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 j0CHarVu007964 for ; Wed, 12 Jan 2005 10:36:53 -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 <0IA700FJ0SXHPU@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 12 Jan 2005 10:36:53 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA7005Y7SXGUK@mail.sun.net> for atom-syntax@imc.org; Wed, 12 Jan 2005 10:36:53 -0700 (MST) Date: Wed, 12 Jan 2005 09:36:58 -0800 From: Tim Bray Subject: Re: Questions about -04 In-reply-to: <41E55708.5060804@franklinmint.fm> To: Robert Sayre Cc: Atom Syntax , Norman Walsh Message-id: <8F58E327-64C0-11D9-909F-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: <873bx6x1z1.fsf@nwalsh.com> <41E55708.5060804@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 12, 2005, at 8:57 AM, Robert Sayre wrote: > Or, for that matter, different titles and URIs. I think we should drop > the restriction. Any time you drop a restriction, you're adding complexity to implementations. Might be worthwhile, but should be born in mind. -Tim From owner-atom-syntax@mail.imc.org Wed Jan 12 13:41: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 NAA04501 for ; Wed, 12 Jan 2005 13:41: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 j0CIRpXo049332; Wed, 12 Jan 2005 10: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 j0CIRpRv049331; Wed, 12 Jan 2005 10:27:51 -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 j0CIRon6049244 for ; Wed, 12 Jan 2005 10:27: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 (sccrmhc11) with SMTP id <20050112182748011003feb5e>; Wed, 12 Jan 2005 18:27:48 +0000 Date: Wed, 12 Jan 2005 11:27:46 -0700 Subject: Re: Questions about -04 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: <41E55708.5060804@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 Wednesday, January 12, 2005, at 09:57 AM, Robert Sayre wrote: >> 3. 4.2.2 says >> >> atom:head elements MUST NOT contain more than one atom:link element >> with a rel attribute value of "alternate" that has the same type >> attribute value. >> >> What if the atom:link elments have different hreflang values? >> > > Or, for that matter, different titles and URIs. I think we should drop > the restriction. type: The reason for allowing multiple alternate links of different typs is obvious enough: you might have an HTML version, an Atom version (the current feed), an RSS 1.0 version, an RSS 2.0 version, a PDF version, etc. The client could decide which link to render (and could render more than one) based on its own processing capabilities, and perhaps a user preference. No restriction. hreflang: Again, obvious: an English version, a Spanish version, a Japanese version, etc. The client could decide which to render based on the user's language preference. Drop the restriction. title: What use would there be for this? If you just can't decide which of two titles to give your webpage??? And what would a client do with it? Choose one at random? Render both--two links identical except for their title? No benefit, plenty of detriment. Keep the restriction. uri: An argument could be made for this one. For example, you might have two HTML versions: one using frames, and one that doesn't; one for broadband connections, one for dialup, etc. The client would have to render them all, or pick one essentially randomly (eg., the first one), but at least there's a reason for it. I wouldn't oppose dropping the restriction here. From owner-atom-syntax@mail.imc.org Wed Jan 12 13:44: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 NAA04622 for ; Wed, 12 Jan 2005 13:44: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 j0CIS7HE049393; Wed, 12 Jan 2005 10:28: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 j0CIS7hA049392; Wed, 12 Jan 2005 10:28:07 -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 j0CIS6sK049354 for ; Wed, 12 Jan 2005 10:28:07 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 36256 messnum 5112087 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 12 Jan 2005 18:28:04 -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 36256) with SMTP; 12 Jan 2005 18:28:04 -0000 Message-ID: <41E56C46.1000805@dehora.net> Date: Wed, 12 Jan 2005 18:28:22 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: Questions about -04 References: <873bx6x1z1.fsf@nwalsh.com> <41E55708.5060804@franklinmint.fm> In-Reply-To: <41E55708.5060804@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: > > Norman Walsh wrote: > >> 2. Why MUST a feed point to an alternate version. What if the feed is all >> I publish? >> > > I don't know. I say we drop it. +1. >> 3. 4.2.2 says >> >> atom:head elements MUST NOT contain more than one atom:link element >> with a rel attribute value of "alternate" that has the same type >> attribute value. >> >> What if the atom:link elments have different hreflang values? >> > Or, for that matter, different titles and URIs. I think we should drop > the restriction. I'm not sure dropping the restriction fixes anything. I think your concerns indicate a latent problem with the link construct (no news there I guess); Methinks @rel is co-occurent and meta-markup at the same time, ie the value in @rel seems to want to scope over and constrain the possible other attribute values in its atom:link - and in other sibling atom:link elements for that matter. I say wait a bit before deciding. >> 5. 7.1 says >> >> Processing [W3C.REC-xmldsig-core-20020212]. Other XML signature >> mechanisms MUST NOT be used on the document element of an Atom >> document. >> >> Are we sure we want to prohibit them? >> >> > I think we should drop that sentence. +1. cheers Bill From owner-atom-syntax@mail.imc.org Wed Jan 12 15:47: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 PAA12988 for ; Wed, 12 Jan 2005 15:47: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 j0CKUrxD057304; Wed, 12 Jan 2005 12:30: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 j0CKUqdW057303; Wed, 12 Jan 2005 12:30: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-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 j0CKUmM8057232 for ; Wed, 12 Jan 2005 12:30:52 -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 j0CKUqVu018579 for ; Wed, 12 Jan 2005 13:30:52 -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 <0IA8007010XP3C@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Wed, 12 Jan 2005 15:30:51 -0500 (EST) Received: from localhost (vpn-129-150-35-209.Central.Sun.COM [129.150.35.209]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IA8005Q80ZAOD@bur-mail1.east.sun.com> for atom-syntax@imc.org; Wed, 12 Jan 2005 15:30:51 -0500 (EST) Received: from ndw by localhost with local (Exim 4.34) id 1Cop8R-0000OO-6m for atom-syntax@imc.org; Wed, 12 Jan 2005 15:30:31 -0500 X-URL: http://nwalsh.com/ Date: Wed, 12 Jan 2005 15:30:30 -0500 From: Norman Walsh Subject: RELAX NG for -04 To: Atom Syntax Message-id: <87ekgqgzkp.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: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Only lightly tested, and still a work in progress, but for curious... --=-=-= Content-Type: application/octet-stream Content-Disposition: attachment; filename=atom.rnc Content-Transfer-Encoding: base64 IyAtKi0gUmVsYXggTkcgLSotCgpuYW1lc3BhY2UgbG9jYWwgPSAiIgpuYW1lc3BhY2UgYXRvbSA9 ICJodHRwOi8vcHVybC5vcmcvYXRvbS9ucyNkcmFmdC1pZXRmLWF0b21wdWItZm9ybWF0LTA0Igpu YW1lc3BhY2UgcyA9ICJodHRwOi8vd3d3LmFzY2MubmV0L3htbC9zY2hlbWF0cm9uIgoKc3RhcnQg PSBhdG9tRmVlZCB8IGF0b21FbnRyeQoKIyBBdHRyaWJ1dGUgZGVmaW5pdGlvbnMKCmF0b21Db21t b25BdHRyaWJ1dGVzID0KICAgYXR0cmlidXRlIHhtbDpiYXNlIHsgYXRvbVVyaSB9PywKICAgYXR0 cmlidXRlIHhtbDpsYW5nIHsgYXRvbUxhbmd1YWdlVGFnIH0/CgphdG9tVmVyc2lvbkF0dHJpYnV0 ZSA9CiAgIGF0dHJpYnV0ZSB2ZXJzaW9uIHsgImRyYWZ0LWlldGYtYXRvbXB1Yi1mb3JtYXQtMDQg OiBkbyBub3QgZGVwbG95IiB9CgojIENvbW1vbiBBdG9tIENvbnN0cnVjdHMKCmF0b21QbGFpblRl eHRDb25zdHJ1Y3QgPQogICBhdG9tQ29tbW9uQXR0cmlidXRlcywKICAgYXR0cmlidXRlIHR5cGUg eyAiVEVYVCIgfCAiSFRNTCIgfT8sCiAgIHRleHQKCmF0b21YSFRNTFRleHRDb25zdHJ1Y3QgPQog ICBhdG9tQ29tbW9uQXR0cmlidXRlcywKICAgYXR0cmlidXRlIHR5cGUgeyAiWEhUTUwiIH0sCiAg ICh0ZXh0fGFueUVsZW1lbnQpKgoKYXRvbVRleHRDb25zdHJ1Y3QgPSBhdG9tUGxhaW5UZXh0Q29u c3RydWN0IHwgYXRvbVhIVE1MVGV4dENvbnN0cnVjdAoKYXRvbVBlcnNvbkNvbnN0cnVjdCA9CiAg IGF0b21Db21tb25BdHRyaWJ1dGVzLAogICAoZWxlbWVudCBhdG9tOm5hbWUgeyB0ZXh0IH0KICAg ICYgZWxlbWVudCBhdG9tOnVyaSB7IGF0b21VcmkgfT8KICAgICYgZWxlbWVudCBhdG9tOmVtYWls IHsgYXRvbUVtYWlsQWRkcmVzcyB9PykKCmF0b21EYXRlQ29uc3RydWN0ID0KICAgYXRvbUNvbW1v bkF0dHJpYnV0ZXMsCiAgIHhzZDpkYXRlVGltZQoKYXRvbVNlcnZpY2VDb25zdHJ1Y3QgPQogICBh dG9tQ29tbW9uQXR0cmlidXRlcywKICAgYXR0cmlidXRlIG5hbWUgeyB0ZXh0IH0sCiAgIGF0dHJp YnV0ZSBocmVmIHsgYXRvbVVyaSB9CgphdG9tTGlua0NvbnN0cnVjdCA9CiAgIGF0b21Db21tb25B dHRyaWJ1dGVzLAogICBhdHRyaWJ1dGUgcmVsIHsgYXRvbU5DTmFtZSB8IGF0b21VcmkgfT8sCiAg IGF0dHJpYnV0ZSB0eXBlIHsgYXRvbU1lZGlhVHlwZSB9PywKICAgYXR0cmlidXRlIGhyZWYgeyBh dG9tVXJpIH0sCiAgIGF0dHJpYnV0ZSBocmVmbGFuZyB7IGF0b21MYW5ndWFnZVRhZyB9PywKICAg YXR0cmlidXRlIHRpdGxlIHsgdGV4dCB9PywKICAgYXR0cmlidXRlIGxlbmd0aCB7IHRleHQgfT8s CiAgIGVtcHR5CgphdG9tSWRlbnRpdHlDb25zdHJ1Y3QgPQogICBhdG9tQ29tbW9uQXR0cmlidXRl cywKICAgKGF0b21VcmkpCgphdG9tQ2F0ZWdvcnlDb25zdHJ1Y3QgPQogICBhdG9tQ29tbW9uQXR0 cmlidXRlcywKICAgYXR0cmlidXRlIHRlcm0geyB0ZXh0IH0sCiAgIGF0dHJpYnV0ZSBzY2hlbWUg eyBhdG9tVXJpIH0/LAogICBhdHRyaWJ1dGUgbGFiZWwgeyB0ZXh0IH0/CgojIGF0b206ZmVlZAoj IFRPRE86IFRlc3QgZm9yIG11bHRpcGxlIGF0b206bGluay9AcmVsPSdhbHRlcm5hdGUnIHdpdGgg dGhlIHNhbWUgQHR5cGUKIyBUaGUgZm9sbG93aW5nIHRlc3RzIGFyZSBzaW1wbGUgdG8gZG8sIGJ1 dCBteSB2YWxpZGF0b3IgaXMgZ2l2aW5nIG1lIHRyb3VibGUuCiMgVE9ETzogRGVidWcgYW5kIGFk ZCB0aGVtIGJhY2sKIyAgICAgICBUZXN0IGZvciBhdCBsZWFzdCBvbmUgYXRvbTpsaW5rL0ByZWw9 J2FsdGVybmF0ZScKIyAgICAgICBUZXN0IGZvciBhdG9tOmF1dGhvciBvciBhbGwgYXRvbTplbnRy eSBoYXZlIGF0b206YXV0aG9yCgojIGF0b206ZmVlZAoKYXRvbUZlZWQgPQogICBlbGVtZW50IGF0 b206ZmVlZCB7CiAgICAgIGF0b21Db21tb25BdHRyaWJ1dGVzLAogICAgICBhdG9tVmVyc2lvbkF0 dHJpYnV0ZSwKICAgICAgKGF0b21IZWFkCiAgICAgICAmIGF0b21FbnRyeSoKICAgICAgICYgYW55 RWxlbWVudCopCiAgIH0KCiMgYXRvbTpoZWFkCgphdG9tSGVhZCA9CiAgIFsKICAgICAgczpydWxl IFsKICAgICAgICAgY29udGV4dCA9ICJhdG9tOmhlYWQiCiAgICAgICAgIHM6YXNzZXJ0IFsKICAg ICAgICAgICAgdGVzdCA9ICJhdG9tOmxpbmtbQHJlbD0nYWx0ZXJuYXRlJ10iCiAgICAgICAgICAg ICJBbiBhdG9tOmZlZWQgbXVzdCBoYXZlIGF0IGxlYXN0IG9uZSBsaW5rIGVsZW1lbnQgd2l0aCBh IHJlbCBhdHRyaWJ1dGUgb2YgJ2FsdGVybmF0ZScuIgogICAgICAgICBdCiAgICAgIF0KICAgICAg czpydWxlIFsKICAgICAgICAgY29udGV4dCA9ICJhdG9tOmhlYWQiCiAgICAgICAgIHM6YXNzZXJ0 IFsKICAgICAgICAgICAgdGVzdCA9ICJhdG9tOmF1dGhvciBvciBub3QoLi4vYXRvbTplbnRyeVtj b3VudChhdG9tOmF1dGhvcikgPSAwXSkiCiAgICAgICAgICAgICJBbiBhdG9tOmZlZWQgbXVzdCBo YXZlIGFuIGF0b206YXV0aG9yIHVubGVzcyBhbGwgb2YgaXRzIGF0b206ZW50cnkgY2hpbGRyZW4g aGF2ZSBhbiBhdG9tOmF1dGhvci4iCiAgICAgICAgIF0KICAgICAgXQogICBdCiAgIGVsZW1lbnQg YXRvbTpoZWFkIHsKICAgICAgYXRvbUNvbW1vbkF0dHJpYnV0ZXMsCiAgICAgIChhdG9tVGl0bGUK ICAgICAgICYgYXRvbUxpbmsrCiAgICAgICAmIGF0b21DYXRlZ29yeSoKICAgICAgICYgYXRvbUlu dHJvc3BlY3Rpb24/CiAgICAgICAmIGF0b21Qb3N0PwogICAgICAgJiBhdG9tQXV0aG9yPwogICAg ICAgJiBhdG9tQ29udHJpYnV0b3IqCiAgICAgICAmIGF0b21UYWdsaW5lPwogICAgICAgJiBhdG9t SWQ/CiAgICAgICAmIGF0b21HZW5lcmF0b3I/CiAgICAgICAmIGF0b21Db3B5cmlnaHQ/CiAgICAg ICAmIGF0b21JbmZvPwogICAgICAgJiBhdG9tVXBkYXRlZAogICAgICAgJiBhbnlFbGVtZW50KikK ICAgfQoKIyBhdG9tOnRpdGxlCgphdG9tVGl0bGUgPSBlbGVtZW50IGF0b206dGl0bGUgeyBhdG9t VGV4dENvbnN0cnVjdCB9CgojIGF0b206bGluawoKYXRvbUxpbmsgPSBlbGVtZW50IGF0b206bGlu ayB7IGF0b21MaW5rQ29uc3RydWN0IH0KCiMgYXRvbTpjYXRlZ29yeQoKYXRvbUNhdGVnb3J5ID0g ZWxlbWVudCBhdG9tOmNhdGVnb3J5IHsgYXRvbUNhdGVnb3J5Q29uc3RydWN0IH0KCiMgYXRvbTpp bnRyb3NwZWN0aW9uCgphdG9tSW50cm9zcGVjdGlvbiA9IGVsZW1lbnQgYXRvbTppbnRyb3NwZWN0 aW9uIHsgYXRvbVNlcnZpY2VDb25zdHJ1Y3QgfQoKIyBhdG9tOnBvc3QKCmF0b21Qb3N0ID0gZWxl bWVudCBhdG9tOnBvc3QgeyBhdG9tU2VydmljZUNvbnN0cnVjdCB9CgojIGF0b206YXV0aG9yCgph dG9tQXV0aG9yID0gZWxlbWVudCBhdG9tOmF1dGhvciB7IGF0b21QZXJzb25Db25zdHJ1Y3QgfQoK IyBhdG9tOmNvbnRyaWJ1dG9yCgphdG9tQ29udHJpYnV0b3IgPSBlbGVtZW50IGF0b206Y29udHJp YnV0b3IgeyBhdG9tUGVyc29uQ29uc3RydWN0IH0KCiMgYXRvbTp0YWdsaW5lCgphdG9tVGFnbGlu ZSA9IGVsZW1lbnQgYXRvbTp0YWdsaW5lIHsgYXRvbVRleHRDb25zdHJ1Y3QgfQoKIyBhdG9tOmlk CgphdG9tSWQgPSBlbGVtZW50IGF0b206aWQgeyBhdG9tSWRlbnRpdHlDb25zdHJ1Y3QgfQoKIyBh dG9tOmdlbmVyYXRvcgoKYXRvbUdlbmVyYXRvciA9IGVsZW1lbnQgYXRvbTpnZW5lcmF0b3Igewog ICBhdG9tQ29tbW9uQXR0cmlidXRlcywKICAgYXR0cmlidXRlIHVybCB7IGF0b21VcmkgfT8sCiAg IGF0dHJpYnV0ZSB2ZXJzaW9uIHsgdGV4dCB9PywKICAgdGV4dAp9CgojIGF0b206Y29weXJpZ2h0 CgphdG9tQ29weXJpZ2h0ID0gZWxlbWVudCBhdG9tOmNvcHlyaWdodCB7IGF0b21UZXh0Q29uc3Ry dWN0IH0KCiMgYXRvbTppbmZvCgphdG9tSW5mbyA9IGVsZW1lbnQgYXRvbTppbmZvIHsgYXRvbVRl eHRDb25zdHJ1Y3QgfQoKIyBhdG9tOm1vZGlmaWVkCiMgVE9ETzogVGVzdCBmb3IgYSB0aW1lem9u ZSB0aGF0IFNIT1VMRCBiZSBVVEMKCmF0b21VcGRhdGVkID0gZWxlbWVudCBhdG9tOnVwZGF0ZWQg eyBhdG9tRGF0ZUNvbnN0cnVjdCB9CgojIGF0b206ZW50cnkKIyBUT0RPOiBUZXN0IGZvciBtdWx0 aXBsZSBhdG9tOmxpbmsgQHJlbD0nYWx0ZXJuYXRlJyB3aXRoIHRoZSBzYW1lIEB0eXBlCiMgVE9E TzogVGVzdCBmb3IgcmVxdWlyZWQgYXRvbTpzdW1tYXJ5CgphdG9tRW50cnkgPQogICBbCiAgICAg IHM6cnVsZSBbCiAgICAgICAgIGNvbnRleHQgPSAiL2F0b206ZW50cnkiCiAgICAgICAgIHM6YXNz ZXJ0IFsKICAgICAgICAgICAgdGVzdCA9ICJAdmVyc2lvbiIKICAgICAgICAgICAgIlRoZSB2ZXJz aW9uIGF0dHJpYnV0ZSBpcyByZXF1aXJlZCBvbiBzdGFuZGFsb25lIGF0b206ZW50cnkgZWxlbWVu dHMuIgogICAgICAgICBdCiAgICAgIF0KICAgICAgczpydWxlIFsKICAgICAgICAgY29udGV4dCA9 ICJhdG9tOmVudHJ5IgogICAgICAgICBzOmFzc2VydCBbCiAgICAgICAgICAgIHRlc3QgPSAiYXRv bTpsaW5rW0ByZWw9J2FsdGVybmF0ZSddIgogICAgICAgICAgICAiQW4gYXRvbTplbnRyeSBtdXN0 IGhhdmUgYXQgbGVhc3Qgb25lIGxpbmsgZWxlbWVudCB3aXRoIGEgcmVsIGF0dHJpYnV0ZSBvZiAn YWx0ZXJuYXRlJy4iCiAgICAgICAgIF0KICAgICAgXQogICAgICBzOnJ1bGUgWwogICAgICAgICBj b250ZXh0ID0gImF0b206ZW50cnkiCiAgICAgICAgIHM6YXNzZXJ0IFsKICAgICAgICAgICAgdGVz dCA9ICJhdG9tOmF1dGhvciBvciAuLi9hdG9tOmF1dGhvciIKICAgICAgICAgICAgIkFuIGF0b206 ZW50cnkgbXVzdCBoYXZlIGFuIGF0b206YXV0aG9yIGlmIHRoZSBwYXJlbnQgYXRvbTpmZWVkIGRv ZXMgbm90LiIKICAgICAgICAgXQogICAgICBdCiAgIF0KICAgZWxlbWVudCBhdG9tOmVudHJ5IHsK ICAgICAgYXRvbUNvbW1vbkF0dHJpYnV0ZXMsCiAgICAgIGF0b21WZXJzaW9uQXR0cmlidXRlPywK ICAgICAgKGF0b21UaXRsZQogICAgICAgJiBhdG9tTGluaysKICAgICAgICYgYXRvbUNhdGVnb3J5 KgogICAgICAgJiBhdG9tRWRpdD8KICAgICAgICYgYXRvbUF1dGhvcj8KICAgICAgICYgYXRvbUNv bnRyaWJ1dG9yKgogICAgICAgJiBhdG9tSG9zdD8KICAgICAgICYgYXRvbUlkPwogICAgICAgJiBh dG9tVXBkYXRlZAogICAgICAgJiBhdG9tUHVibGlzaGVkPwogICAgICAgJiBhdG9tU3VtbWFyeT8K ICAgICAgICYgYXRvbUNvbnRlbnQ/CiAgICAgICAmIGF0b21Db3B5cmlnaHQ/CiAgICAgICAmIGF0 b21IZWFkPwogICAgICAgJiBhbnlFbGVtZW50KikKICAgfQoKIyBhdG9tOmVkaXQKCmF0b21FZGl0 ID0gZWxlbWVudCBhdG9tOmVkaXQgeyBhdG9tU2VydmljZUNvbnN0cnVjdCB9CgojIGF0b206aG9z dAoKIyBUT0RPOiB0aWdodGVuIHRoaXMgdXAKYXRvbUhvc3QgPSBlbGVtZW50IGF0b206aG9zdCB7 IHRleHQgfQoKIyBhdG9tOnB1Ymxpc2hlZAoKYXRvbVB1Ymxpc2hlZCA9IGVsZW1lbnQgYXRvbTpw dWJsaXNoZWQgeyBhdG9tRGF0ZUNvbnN0cnVjdCB9CgojIGF0b206c3VtbWFyeQoKYXRvbVN1bW1h cnkgPSBlbGVtZW50IGF0b206c3VtbWFyeSB7IGF0b21UZXh0Q29uc3RydWN0IH0KCiMgYXRvbTpj b250ZW50CgphdG9tSW5saW5lVGV4dENvbnRlbnQgPQogICBlbGVtZW50IGF0b206Y29udGVudCB7 CiAgICAgIGF0b21Db21tb25BdHRyaWJ1dGVzLAogICAgICBhdHRyaWJ1dGUgdHlwZSB7ICJURVhU IiB8ICJIVE1MIiB8IGF0b21NZWRpYVR5cGUgfT8sCiAgICAgICh0ZXh0KSoKICAgfQoKYXRvbUlu bGluZVhIVE1MQ29udGVudCA9CiAgIGVsZW1lbnQgYXRvbTpjb250ZW50IHsKICAgICAgYXRvbUNv bW1vbkF0dHJpYnV0ZXMsCiAgICAgIGF0dHJpYnV0ZSB0eXBlIHsgIlhIVE1MIiB8IGF0b21NZWRp YVR5cGUgfT8sCiAgICAgICh0ZXh0fGFueUVsZW1lbnQpKgogICB9CgphdG9tT3V0T2ZMaW5lQ29u dGVudCA9CiAgIGVsZW1lbnQgYXRvbTpjb250ZW50IHsKICAgICAgYXRvbUNvbW1vbkF0dHJpYnV0 ZXMsCiAgICAgIGF0dHJpYnV0ZSB0eXBlIHsgIlRFWFQiIHwgIkhUTUwiIHwgIlhIVE1MIiB8IGF0 b21NZWRpYVR5cGUgfT8sCiAgICAgIGF0dHJpYnV0ZSBzcmMgeyBhdG9tVXJpIH0sCiAgICAgIGVt cHR5CiAgIH0KCmF0b21Db250ZW50ID0gYXRvbUlubGluZVRleHRDb250ZW50CiB8IGF0b21Jbmxp bmVYSFRNTENvbnRlbnQKIHwgYXRvbU91dE9mTGluZUNvbnRlbnQKCiMgTG93LWxldmVsIHNpbXBs ZSB0eXBlcwoKIyBUT0RPOiBjYW4gYW55dGhpbmcgbW9yZSBzcGVjaWZpYyBiZSBzYWlkIGFib3V0 IHRoZXNlIHR5cGVzPwoKYXRvbU5DTmFtZSA9IHhzZDpzdHJpbmcgeyBtaW5MZW5ndGggPSAiMSIg cGF0dGVybiA9ICJbXjpdKiIgfQphdG9tTWVkaWFUeXBlID0gdGV4dAphdG9tTGFuZ3VhZ2VUYWcg PSB0ZXh0CmF0b21VcmkgPSB0ZXh0CmF0b21FbWFpbEFkZHJlc3MgPSB0ZXh0CgojIEV4dGVuc2li aWxpdHkKCmFueUZvcmVpZ25FbGVtZW50ID0KICAgZWxlbWVudCAqIC0gKGF0b206KiB8IGxvY2Fs OiopCiAgIHsKICAgICAgKGF0dHJpYnV0ZSAqIHsgdGV4dCB9CiAgICAgICB8IHRleHQKICAgICAg IHwgYW55Rm9yZWlnbkVsZW1lbnQpKgogICB9CgphbnlGb3JlaWduQXR0cmlidXRlID0KICAgYXR0 cmlidXRlICogLSAoYXRvbToqIHwgbG9jYWw6KiB8IHhtbDoqKSB7IHRleHQgfQoKYW55RWxlbWVu dCA9CiAgIGVsZW1lbnQgKiAtIGF0b206KgogICB7CiAgICAgIChhdHRyaWJ1dGUgKiB7IHRleHQg fQogICAgICAgfCB0ZXh0CiAgICAgICB8IGFueUVsZW1lbnQpKgogICB9CgojIEVPRgo= --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Be seeing you, norm =2D-=20 Norman Walsh | Simplification good! Oversimplification http://nwalsh.com/ | bad!--Larry Wall --=-=-=-- --==-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBB5YjmOyltUcwYWjsRAjnEAJ4758JwRkMheCgP6u/XV7Lbd1JrggCgrUwM zzG77k+2mAPh1sXbQ2qse0k= =B2oU -----END PGP SIGNATURE----- --==-=-=-- From owner-atom-syntax@mail.imc.org Wed Jan 12 16:31: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 QAA19444 for ; Wed, 12 Jan 2005 16:31: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 j0CLKA1Q006684; Wed, 12 Jan 2005 13: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 j0CLKAb5006683; Wed, 12 Jan 2005 13:20:10 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0CLK8sk006406 for ; Wed, 12 Jan 2005 13:20:09 -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 <20050112211952.POYB19851.mta08-winn.mailhost.ntl.com@aamta06-winn.mailhost.ntl.com> for ; Wed, 12 Jan 2005 21:19:52 +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 <20050112211952.RQIA7271.aamta06-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com> for ; Wed, 12 Jan 2005 21:19:52 +0000 Date: Wed, 12 Jan 2005 21:19:50 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <1113271276.20050112211950@djpowell.net> To: atom-syntax@imc.org Subject: Posted PaceExtensionConstruct 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 just posted PaceExtensionConstruct. As it is an extensibility Pace, it would be good if we could schedule it for discussion with the others. http://www.intertwingly.net/wiki/pie/PaceExtensionConstruct -- Dave From owner-atom-syntax@mail.imc.org Wed Jan 12 17:09: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 RAA22216 for ; Wed, 12 Jan 2005 17:09: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 j0CLsVYf041485; Wed, 12 Jan 2005 13:54: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 j0CLsViR041484; Wed, 12 Jan 2005 13:54: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-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 j0CLsTkg041454 for ; Wed, 12 Jan 2005 13:54:30 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.110] (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 j0CLsTKj004225; Wed, 12 Jan 2005 16:54:29 -0500 (EST) Message-ID: <41E59C93.4050001@intertwingly.net> Date: Wed, 12 Jan 2005 16:54:27 -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: Questions about -04 References: <873bx6x1z1.fsf@nwalsh.com> In-Reply-To: <873bx6x1z1.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: > 2. Why MUST a feed point to an alternate version. What if the feed is all > I publish? Deja vu: http://www.imc.org/atom-syntax/mail-archive/msg08836.html I'm -1 on removing this restriction. - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Jan 12 17:21: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 RAA23099 for ; Wed, 12 Jan 2005 17:21: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 j0CMDsu7058018; Wed, 12 Jan 2005 14:13: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 j0CMDsNB058015; Wed, 12 Jan 2005 14:13: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 j0CMDqia057820 for ; Wed, 12 Jan 2005 14:13: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 j0CMC8B0002925; Wed, 12 Jan 2005 22:12:13 GMT In-Reply-To: <41E59C93.4050001@intertwingly.net> References: <873bx6x1z1.fsf@nwalsh.com> <41E59C93.4050001@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-559192896; protocol="application/pkcs7-signature" Message-Id: Cc: Atom Syntax , Norman Walsh From: Graham Subject: Re: Questions about -04 Date: Wed, 12 Jan 2005 22:12:07 +0000 To: Sam Ruby X-Mailer: Apple Mail (2.619) 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-1-559192896 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 12 Jan 2005, at 9:54 pm, Sam Ruby wrote: >> 2. Why MUST a feed point to an alternate version. What if the feed is >> all >> I publish? > > Deja vu: > > http://www.imc.org/atom-syntax/mail-archive/msg08836.html > > I'm -1 on removing this restriction. I'm +1 on removing it, and given the number of people who've commented on it over the last year, I think you're outnumbered. Graham --Apple-Mail-1-559192896 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 9w0BCQUxDxcNMDUwMTEyMjIxMjA4WjAjBgkqhkiG9w0BCQQxFgQUkTUqnfQ09lX8tA4YZKGEKPo4 59UweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAmjxxLdFAxdxgJZKlJeTEFjEz AO+3WU0X7qmOIy2Bv/i7PuzFimPPI4eIh2TJUuu+wH19VA4H36tSBMjpBdnncTWZn08qCOPkaC79 Je9u+cnIV2xHdr4AEWDML3tcK87oQUXK/aS5VkHfN7vNUsCZR+neEUVdp1f8luwk8bi6gMGU82zo D8itbQs44C3D4E3u6xq+JcFhGYFlteV4ven73iijDjWRm/3qogLYnqbKJl0KBqa/Ge04JPT46P7R h4NLfWJzaoKyF8wrAgS9SETWZxAlD5jrq06nFFuQ9WRQfx1LifwuxAlqmbSI/Vz0iCCvF9pp79n0 CvIDQLvo6lj9pgAAAAAAAA== --Apple-Mail-1-559192896-- From owner-atom-syntax@mail.imc.org Wed Jan 12 17:45: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 RAA24588 for ; Wed, 12 Jan 2005 17:45: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 j0CMasbO083325; Wed, 12 Jan 2005 14:36: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 j0CMasG6083324; Wed, 12 Jan 2005 14:36:54 -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 j0CMarxZ083248 for ; Wed, 12 Jan 2005 14:36:53 -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 <0IA800DWT6KZ9L90@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Wed, 12 Jan 2005 23:31:47 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IA8004BC6Y6YJ20@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Wed, 12 Jan 2005 23:39:43 +0100 (CET) Date: Wed, 12 Jan 2005 23:41:56 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: Questions about -04 In-reply-to: <41E59C93.4050001@intertwingly.net> To: Sam Ruby , 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: <873bx6x1z1.fsf@nwalsh.com> <41E59C93.4050001@intertwingly.net> 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 Wed, 12 Jan 2005 16:54:27 -0500, Sam Ruby wrote: >> 2. Why MUST a feed point to an alternate version. What if the feed is >> all I publish? > > Deja vu: > > http://www.imc.org/atom-syntax/mail-archive/msg08836.html I think this goes along with the alternate entry discussion which ended up in these paces: > I'm -1 on removing this restriction. I think alternate links for both entries and feeds should be optional, but I'm more eager to have it be optional for entries. -- 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 Wed Jan 12 18:00: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 SAA25608 for ; Wed, 12 Jan 2005 18:00: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 j0CMq1LY097799; Wed, 12 Jan 2005 14:52: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 j0CMq1Mb097798; Wed, 12 Jan 2005 14:52:01 -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 j0CMq0a2097677 for ; Wed, 12 Jan 2005 14:52: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 (rwcrmhc11) with SMTP id <2005011222520001300t4fnhe>; Wed, 12 Jan 2005 22:52:00 +0000 Date: Wed, 12 Jan 2005 15:51:58 -0700 Subject: Re: Posted PaceExtensionConstruct 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: <1113271276.20050112211950@djpowell.net> Message-Id: <90CBE0F0-64EC-11D9-AC31-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 > The root element of a Structured Extension construct MAY have > attributes, it MAY contain well-formed XML content, or it MAY be > empty. It took me a minute to realize that the content of a structured extension element could be a text node--that it needn't have element children. The name "structured extension" lends itself to this misperception. Perhaps this paragraph could have a sentence or phrase added to it to ensure that that is clear. For example: The root element of a Structured Extension construct MAY have attributes, it MAY contain well-formed XML content (including unstructured character data), or it MAY be empty. > The presence of an Extension construct MUST NOT redefine the meaning > of another Extension construct or core element. Does this mean that an Extension construct cannot redefine the meaning of another Extension construct from the same namespace, or does it only restrict interaction across namespaces? > The meaning of the namespaced-qualified XML element used as the > property name SHOULD be defined by an Atom extension specification, > or by a compatible vocabulary. I'm not sure I have any idea what this means. Does it mean that extensions should have an Atom-specific document describing them? Is there more to it than that? From owner-atom-syntax@mail.imc.org Wed Jan 12 18:23: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 SAA28451 for ; Wed, 12 Jan 2005 18:23: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 j0CNDvdM021863; Wed, 12 Jan 2005 15:13: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 j0CNDvQ4021861; Wed, 12 Jan 2005 15:13:57 -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 j0CNDv5k021572 for ; Wed, 12 Jan 2005 15:13: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 (rwcrmhc11) with SMTP id <2005011223135601300stps5e>; Wed, 12 Jan 2005 23:13:56 +0000 Date: Wed, 12 Jan 2005 16:13:54 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceMinimalEntryVersioning 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/PaceMinimalEntryVersioning > Multiple instances or versions of the same entry MAY appear in a feed, > index, or archive. I'm in favor of this--it's easy enough to imagine uses for it (like a feed showing the history of a particular entry). > Consumers MAY choose to present or record only the instance or version > of the entry with the latest [[date that indicates change per other > discussion, which is in format-01]]. ...or they may choose to only present the first one, or any other one... I think this sentence shouldn't specify which instance consumers might process. Instead, perhaps: Consumers MAY choose not to present or record all instances or versions of each entry. From owner-atom-syntax@mail.imc.org Wed Jan 12 18:32: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 SAA28983 for ; Wed, 12 Jan 2005 18: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 j0CNPuOL033893; Wed, 12 Jan 2005 15:25: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 j0CNPuRq033892; Wed, 12 Jan 2005 15:25:56 -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 j0CNPumR033833 for ; Wed, 12 Jan 2005 15:25: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 (rwcrmhc12) with SMTP id <2005011223255501400gg2e5e>; Wed, 12 Jan 2005 23:25:56 +0000 Date: Wed, 12 Jan 2005 16:25:53 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceMustUnderstandElement From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <4D78DC0A-64F1-11D9-AC31-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/PaceMustUnderstandElement > Any Atom document MAY contain a single atom:must-understand element, > which, if it appears, MUST be the first child element of the document > element. I think we need to add language stating that aggregators aggregating entries containing elements or attributes from a mU namespace MUST mark that namespace mU in the aggregate feed. This would be somewhat easier to do if this element appeared in atom:head (so that it could be in entry/head). > Each atom:ns element MUST contain only text, with no child elements, > which is to be interpreted as an XML namespace name [XMLNS]. I'd be in favor of a slight change from this: http://example.com/private/27 to either of these: http://example.com/private/27 http://example.com/private/27 The first would be as currently defined. The second of which would mean that the consuming application needn't understand the entire extension, but just the foo and bar elements or attributes. This would enable more applications to process feeds that they are capable of processing; and would protect against cases where an application understands one draft of an extension, but not things added in another draft without changing the namespace. Regardless of whether the extension's namespace SHOULD change in such a case, there's no way for us to be certain whether extension authors will change it or not. From owner-atom-syntax@mail.imc.org Wed Jan 12 18:50: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 SAA00256 for ; Wed, 12 Jan 2005 18:50: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 j0CNgD0V051340; Wed, 12 Jan 2005 15:42: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 j0CNgD8I051339; Wed, 12 Jan 2005 15:42: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 j0CNgDkU051255 for ; Wed, 12 Jan 2005 15:42:13 -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 <2005011223421201200oubmne>; Wed, 12 Jan 2005 23:42:13 +0000 Date: Wed, 12 Jan 2005 16:42:10 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PacePropertyDesign From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <942A597C-64F3-11D9-AC31-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/PacePropertyDesign > * Simple > > The content of the element MUST be CDATA, and have no attributes. Perhaps "character data" instead of "CDATA" would be better, as a quick reading might be taken to imply that the content must be in . > * RDF Resource > > The Element MUST be empty and MUST have a single attribute > denoted by the tuple > > {http://www.w3.org/1999/02/22-rdf-syntax-ns#,resource}. Perhaps those who need to know will understand this, but I haven't the slightest idea what it means. Why does this pace only address child elements of atom:head and atom:entry, and not atom:author, or other arbitrary locations? I noticed that, unlike PaceExtensionConstruct, this pace does not provide any method to signal the difference simple, XML (or "structured") and RDF resource. Could anyone comment on why something like atom:notation might or might not be needed? From owner-atom-syntax@mail.imc.org Wed Jan 12 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 TAA01037 for ; Wed, 12 Jan 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 j0CNrL4L063163; Wed, 12 Jan 2005 15:53: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 j0CNrL93063157; Wed, 12 Jan 2005 15:53:21 -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 j0CNrJ0M063088 for ; Wed, 12 Jan 2005 15:53:20 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.110] (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 j0CNrMCh011813; Wed, 12 Jan 2005 18:53:22 -0500 (EST) Message-ID: <41E5B870.40607@intertwingly.net> Date: Wed, 12 Jan 2005 18:53:20 -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 , Norman Walsh Subject: Re: Questions about -04 References: <873bx6x1z1.fsf@nwalsh.com> <41E59C93.4050001@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 12 Jan 2005, at 9:54 pm, Sam Ruby wrote: > >>> 2. Why MUST a feed point to an alternate version. What if the feed is >>> all >>> I publish? >> >> Deja vu: >> >> http://www.imc.org/atom-syntax/mail-archive/msg08836.html >> >> I'm -1 on removing this restriction. > > I'm +1 on removing it, and given the number of people who've commented > on it over the last year, I think you're outnumbered. Every piece of running code, for all versions of RSS and Atom, expect this data to be present. - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Jan 12 19:01: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 TAA01108 for ; Wed, 12 Jan 2005 19:01: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 j0CNuKQ2067062; Wed, 12 Jan 2005 15:56: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 j0CNuKjQ067061; Wed, 12 Jan 2005 15:56:20 -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 j0CNuKjB067054 for ; Wed, 12 Jan 2005 15:56:20 -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 1CosLA-0003Rh-21; Wed, 12 Jan 2005 23:55:52 +0000 Message-ID: <41E5B923.3030204@franklinmint.fm> Date: Wed, 12 Jan 2005 18:56: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: PacePropertyDesign References: <942A597C-64F3-11D9-AC31-003065EA6144@geckotribe.com> In-Reply-To: <942A597C-64F3-11D9-AC31-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 I never finished this Pace, and it can be considered withdrawn. Robert Sayre Antone Roundy wrote: > > http://www.intertwingly.net/wiki/pie/PacePropertyDesign > >> * Simple >> >> The content of the element MUST be CDATA, and have no attributes. > > Perhaps "character data" instead of "CDATA" would be better, as a > quick reading might be taken to imply that the content must be in > . > >> * RDF Resource >> >> The Element MUST be empty and MUST have a single attribute >> denoted by the tuple >> >> {http://www.w3.org/1999/02/22-rdf-syntax-ns#,resource}. > > Perhaps those who need to know will understand this, but I haven't the > slightest idea what it means. > > Why does this pace only address child elements of atom:head and > atom:entry, and not atom:author, or other arbitrary locations? > > I noticed that, unlike PaceExtensionConstruct, this pace does not > provide any method to signal the difference simple, XML (or > "structured") and RDF resource. Could anyone comment on why something > like atom:notation might or might not be needed? > From owner-atom-syntax@mail.imc.org Wed Jan 12 19: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 TAA02040 for ; Wed, 12 Jan 2005 19:10: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 j0D03hKc075230; Wed, 12 Jan 2005 16:03: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 j0D03hLJ075229; Wed, 12 Jan 2005 16:03:43 -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 j0D03gPY075220 for ; Wed, 12 Jan 2005 16:03:43 -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 <2005011300034201500n5jote>; Thu, 13 Jan 2005 00:03:42 +0000 Date: Wed, 12 Jan 2005 17:03:40 -0700 Subject: Re: Questions about -04 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: <41E5B870.40607@intertwingly.net> Message-Id: <951094EE-64F6-11D9-AC31-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, January 12, 2005, at 04:53 PM, Sam Ruby wrote: > Graham wrote: > >> On 12 Jan 2005, at 9:54 pm, Sam Ruby wrote: >>>> 2. Why MUST a feed point to an alternate version. What if the feed >>>> is all >>>> I publish? >>> >>> Deja vu: >>> >>> http://www.imc.org/atom-syntax/mail-archive/msg08836.html >>> >>> I'm -1 on removing this restriction. >> I'm +1 on removing it, and given the number of people who've >> commented on it over the last year, I think you're outnumbered. > > Every piece of running code, for all versions of RSS and Atom, expect > this data to be present. > ...except CaRP and Grouper. Any others? From owner-atom-syntax@mail.imc.org Wed Jan 12 19:34: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 TAA03628 for ; Wed, 12 Jan 2005 19:34: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 j0D0PFe3099718; Wed, 12 Jan 2005 16:25: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 j0D0PFs2099715; Wed, 12 Jan 2005 16:25: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 j0D0PEfG099671 for ; Wed, 12 Jan 2005 16:25:14 -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 1CosnA-0003gQ-Hy; Thu, 13 Jan 2005 00:24:48 +0000 Message-ID: <41E5BFEC.7000502@franklinmint.fm> Date: Wed, 12 Jan 2005 19:25:16 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Powell CC: atom-syntax@imc.org Subject: Re: Posted PaceExtensionConstruct References: <1113271276.20050112211950@djpowell.net> In-Reply-To: <1113271276.20050112211950@djpowell.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 David Powell wrote: >I've just posted PaceExtensionConstruct. As it is an extensibility >Pace, it would be good if we could schedule it for discussion with the >others. > >http://www.intertwingly.net/wiki/pie/PaceExtensionConstruct > > I like this one. I think the "atom:notation" attribute is useless, though. If it's a simple extension, it will be obvious from the structure of the content, which makes me wonder if the distinction is useful. I can't think of a use case for extension properties in the Person construct. I think we should leave those undefined. The only thing I can think of putting in there is FOAF, but that works just as well as a child of entry. I don't think 9.1.1 or 9.1.2 are necessary. We should also mention what it means to add markup elsewhere. I think we should allow it, make it mustIgnore, and make its meaning undefined. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Jan 12 19:34: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 TAA03647 for ; Wed, 12 Jan 2005 19:34: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 j0D0KjLw095003; Wed, 12 Jan 2005 16:20: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 j0D0Kixe095001; Wed, 12 Jan 2005 16:20: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-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 j0D0Khjk094922 for ; Wed, 12 Jan 2005 16:20:43 -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 j0D0KmVu002450 for ; Wed, 12 Jan 2005 17:20:48 -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 <0IA800AGGBMNGH@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 12 Jan 2005 17:20:48 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA8000U8BMN8A@mail.sun.net> for atom-syntax@imc.org; Wed, 12 Jan 2005 17:20:47 -0700 (MST) Date: Wed, 12 Jan 2005 16:20:52 -0800 From: Tim Bray Subject: Re: PaceMustUnderstandElement In-reply-to: <4D78DC0A-64F1-11D9-AC31-003065EA6144@geckotribe.com> To: Antone Roundy Cc: 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: <4D78DC0A-64F1-11D9-AC31-003065EA6144@geckotribe.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 12, 2005, at 3:25 PM, Antone Roundy wrote: > > http://www.intertwingly.net/wiki/pie/PaceMustUnderstandElement > >> Any Atom document MAY contain a single atom:must-understand element, >> which, if it appears, MUST be the first child element of the document >> element. > > I think we need to add language Your suggestions are reasonable but have no chance. There are some people who don't see the need for PaceMustUnderstandElement at all, and if we are going to have any chance at overcoming their objections, the cost must be kept very near zero. -Tim From owner-atom-syntax@mail.imc.org Wed Jan 12 19:35: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 TAA03706 for ; Wed, 12 Jan 2005 19:35: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 j0D0RoW5002526; Wed, 12 Jan 2005 16: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 j0D0Ro7R002525; Wed, 12 Jan 2005 16:27:50 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0D0RnVd002496 for ; Wed, 12 Jan 2005 16:27:49 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta03-winn.mailhost.ntl.com ([212.250.162.8]) by mta05-winn.mailhost.ntl.com with ESMTP id <20050113002749.GQQP24912.mta05-winn.mailhost.ntl.com@aamta03-winn.mailhost.ntl.com>; Thu, 13 Jan 2005 00:27:49 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta03-winn.mailhost.ntl.com with ESMTP id <20050113002749.STIH9818.aamta03-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Thu, 13 Jan 2005 00:27:49 +0000 Date: Thu, 13 Jan 2005 00:27:47 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <753914788.20050113002747@djpowell.net> To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: Posted PaceExtensionConstruct In-Reply-To: <90CBE0F0-64EC-11D9-AC31-003065EA6144@geckotribe.com> References: <1113271276.20050112211950@djpowell.net> <90CBE0F0-64EC-11D9-AC31-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 Wednesday, January 12, 2005, 10:51:58 PM, you wrote: >> The root element of a Structured Extension construct MAY have >> attributes, it MAY contain well-formed XML content, or it MAY be >> empty. > It took me a minute to realize that the content of a structured > extension element could be a text node--that it needn't have element > children. > The name "structured extension" lends itself to this > misperception. I considered calling them Custom Extensions - maybe that would have been clearer? > Perhaps this paragraph could have a sentence or phrase > added to it to ensure that that is clear. For example: > The root element of a Structured Extension construct MAY have > attributes, it MAY contain well-formed XML content (including > unstructured character data), or it MAY be empty. Yes, that probably is clearer. >> The presence of an Extension construct MUST NOT redefine the meaning >> of another Extension construct or core element. > Does this mean that an Extension construct cannot redefine the meaning > of another Extension construct from the same namespace, or does it only > restrict interaction across namespaces? The intention is to assist in the interpretation of a known extension amongst unknown extensions. The proposal doesn't give any special status to elements belonging to the same namespace. The isolation applies accross instances of Extension constructs. For Structured Extension construct, because the interpretation of its contents is determined by the extension, it is possible for attributes, and sub-elements to overide each other within a construct, but not accross constructs. >> The meaning of the namespaced-qualified XML element used as the >> property name SHOULD be defined by an Atom extension specification, >> or by a compatible vocabulary. > I'm not sure I have any idea what this means. I haven't seen any discussion about whether there will be any registration procedure for extensions, so I haven't elaborated much on this section. > Does it mean that extensions should have an Atom-specific document > describing them? Simple Extension constructs may be defined for more general use than just within Atom - the PRISM vocabulary for example. Extensions designed specifically for Atom need to be specified. I didn't actually use the word "document", but documenting them would be a good idea. > Is there more to it than that? No, not really. It basically just means: "somebody needs to define an extension before it can be used". Were you having trouble with the "Atom extension specification" bit in just 9.1.1, or for 9.1.2 aswell? Would it help if I made another bulleted list for what should be defined for 9.1.1? -- Dave From owner-atom-syntax@mail.imc.org Wed Jan 12 19:49: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 TAA05066 for ; Wed, 12 Jan 2005 19:49: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 j0D0fRx0018760; Wed, 12 Jan 2005 16: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 j0D0fRs7018759; Wed, 12 Jan 2005 16:41:27 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0D0fQiG018649 for ; Wed, 12 Jan 2005 16:41:26 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta08-winn.mailhost.ntl.com ([212.250.162.8]) by mta13-winn.mailhost.ntl.com with ESMTP id <20050113004126.BZAU10495.mta13-winn.mailhost.ntl.com@aamta08-winn.mailhost.ntl.com>; Thu, 13 Jan 2005 00:41:26 +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 <20050113004126.IRRR7419.aamta08-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Thu, 13 Jan 2005 00:41:26 +0000 Date: Thu, 13 Jan 2005 00:41:24 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <232817669.20050113004124@djpowell.net> To: Robert Sayre CC: atom-syntax@imc.org Subject: Re: Posted PaceExtensionConstruct In-Reply-To: <41E5BFEC.7000502@franklinmint.fm> References: <1113271276.20050112211950@djpowell.net> <41E5BFEC.7000502@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 Thursday, January 13, 2005, 12:25:16 AM, you wrote: > David Powell wrote: >>I've just posted PaceExtensionConstruct. As it is an extensibility >>Pace, it would be good if we could schedule it for discussion with the >>others. >> >>http://www.intertwingly.net/wiki/pie/PaceExtensionConstruct >> >> > I like this one. I think the "atom:notation" attribute is useless, > though. If it's a simple extension, it will be obvious from the > structure of the content, which makes me wonder if the distinction is > useful. Here is a counter example: a) ... some info ... Would you assume that is a Simple Extension or a Structured Extension? ... ... actually it could contain mixed content ... What about now? I think it would be bad to have two different mappings for the same extension depending on whether the instance happenned to contain any tags. > I can't think of a use case for extension properties in the Person > construct. I think we should leave those undefined. The only thing I can > think of putting in there is FOAF, but that works just as well as a > child of entry. There can be multiple Person constructs per entry though. One author, plus several contributors. > I don't think 9.1.1 or 9.1.2 are necessary. Yeah perhaps, my comment to Antone suggests that those paragraphs are no-ops: "somebody needs to define an extension before it can be used" -- Dave From owner-atom-syntax@mail.imc.org Wed Jan 12 19:53: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 TAA05293 for ; Wed, 12 Jan 2005 19:53: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 j0D0lApa025554; Wed, 12 Jan 2005 16: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 j0D0lAsZ025553; Wed, 12 Jan 2005 16:47:10 -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 j0D0lAId025509 for ; Wed, 12 Jan 2005 16:47:10 -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 <20050113004710013009cf6ue>; Thu, 13 Jan 2005 00:47:10 +0000 Date: Wed, 12 Jan 2005 17:47:09 -0700 Subject: Re: Posted PaceExtensionConstruct 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: <753914788.20050113002747@djpowell.net> 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 Wednesday, January 12, 2005, at 05:27 PM, David Powell wrote: > Wednesday, January 12, 2005, 10:51:58 PM, you wrote: >>> The root element of a Structured Extension construct MAY have >>> attributes, it MAY contain well-formed XML content, or it MAY be >>> empty. > >> It took me a minute to realize that the content of a structured >> extension element could be a text node--that it needn't have element >> children. > >> The name "structured extension" lends itself to this >> misperception. > > I considered calling them Custom Extensions - maybe that would have > been clearer? As long as the explanation is clear, "structured extension" is probably fine. > No, not really. It basically just means: "somebody needs to define an > extension before it can be used". > > Were you having trouble with the "Atom extension specification" bit in > just 9.1.1, or for 9.1.2 aswell? Both places, though more in 9.1.1 because of its juxtaposition to the "compatible vocabulary" part, which talks about technologies I'm not particularly familiar with. > Would it help if I made another bulleted list for what should be > defined for 9.1.1? ....I don't know. I'd have to see it and see how it related or didn't relate to the "compatible vocabulary" stuff. I'm not sure 9.1.1 and 9.1.2 are necessary though. From owner-atom-syntax@mail.imc.org Wed Jan 12 19:56: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 TAA05549 for ; Wed, 12 Jan 2005 19:56: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 j0D0nRHw027023; Wed, 12 Jan 2005 16:49: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 j0D0nRCD027022; Wed, 12 Jan 2005 16:49: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 j0D0nRoB027014 for ; Wed, 12 Jan 2005 16:49: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 1CotAZ-0003uA-7j; Thu, 13 Jan 2005 00:48:59 +0000 Message-ID: <41E5C596.1040708@franklinmint.fm> Date: Wed, 12 Jan 2005 19:49:26 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Powell CC: atom-syntax@imc.org Subject: Re: Posted PaceExtensionConstruct References: <1113271276.20050112211950@djpowell.net> <41E5BFEC.7000502@franklinmint.fm> <232817669.20050113004124@djpowell.net> In-Reply-To: <232817669.20050113004124@djpowell.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 David Powell wrote: >I think it would be bad to have two different mappings for the same >extension depending on whether the instance happenned to contain any >tags. > > I'm not sure why you would have two different mappings. Wouldn't it just be an XML property every time? >>I can't think of a use case for extension properties in the Person >>construct. I think we should leave those undefined. The only thing I can >>think of putting in there is FOAF, but that works just as well as a >>child of entry. >> >> > >There can be multiple Person constructs per entry though. One author, >plus several contributors. > > Right, what's the use case? FOAF doesn't need to be contained by atom:person. Again, I'm not up for banning it, just making it undefined. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Jan 12 19: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 TAA05592 for ; Wed, 12 Jan 2005 19: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 j0D0nvmT027461; Wed, 12 Jan 2005 16:49: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 j0D0nv9I027460; Wed, 12 Jan 2005 16:49:57 -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 j0D0nusg027363 for ; Wed, 12 Jan 2005 16:49:56 -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 j0D0mjkg008944; Thu, 13 Jan 2005 00:48:51 GMT In-Reply-To: <951094EE-64F6-11D9-AC31-003065EA6144@geckotribe.com> References: <951094EE-64F6-11D9-AC31-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-568589360; protocol="application/pkcs7-signature" Message-Id: Cc: atom-syntax@imc.org From: Graham Subject: Re: Questions about -04 Date: Thu, 13 Jan 2005 00:48:44 +0000 To: Antone Roundy , Sam Ruby X-Mailer: Apple Mail (2.619) 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-568589360 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 13 Jan 2005, at 12:03 am, Antone Roundy wrote: >> Every piece of running code, for all versions of RSS and Atom, expect >> this data to be present. >> > ...except CaRP and Grouper. Any others? Shrook and NetNewsWire? I believe Sam needs to go sit in the corner until he's learnt his lesson. Bad Sam. Graham --Apple-Mail-2-568589360 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 9w0BCQUxDxcNMDUwMTEzMDA0ODQ0WjAjBgkqhkiG9w0BCQQxFgQUOZJPw8KxFmg7ccZrW1eUuy6X POkweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAIGSDMqpihTlw7bACK94F8E2E 7SlAE8oDbwvFtB9KoULsisb8DUgEuSYPmxeNvZgIziDQhbNa1PYGPwiCrqlDkdTKmQN45b6Bo8uF +7QIvtwSkME0Vqp1r1O7XBrKpSHVgudg4je/Glxdqd+ymMKF3r575SHCKciYvtceg3u5+YswJeG6 epoFt9uD9jZHSW8RT8QUMn0tYhXu/iVZ/ysHnqtjLl2n9c4ZvMGtPOFgVbEkfU8DcEO41HqhJkms XZQBKO21x7Fw7m5jX24Ednk8amnsshzO++cYq4bIka96oz0Q5OBsRhorLhGSrRLB6QBmTX1Rwe6P QXwlI6iKIBd7ugAAAAAAAA== --Apple-Mail-2-568589360-- From owner-atom-syntax@mail.imc.org Wed Jan 12 20:04: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 UAA05938 for ; Wed, 12 Jan 2005 20:04: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 j0D0vtwu036793; Wed, 12 Jan 2005 16:57: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 j0D0vtgJ036792; Wed, 12 Jan 2005 16:57: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 j0D0vsFC036642 for ; Wed, 12 Jan 2005 16:57:55 -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 j0D0vmTV010894; Thu, 13 Jan 2005 00:57:48 GMT In-Reply-To: <1113271276.20050112211950@djpowell.net> References: <1113271276.20050112211950@djpowell.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-569132508; protocol="application/pkcs7-signature" Message-Id: <244067D8-64FE-11D9-8584-000A95DC3D90@mac.com> Cc: atom-syntax@imc.org From: Graham Subject: Re: Posted PaceExtensionConstruct Date: Thu, 13 Jan 2005 00:57:47 +0000 To: David Powell X-Mailer: Apple Mail (2.619) 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-569132508 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 12 Jan 2005, at 9:19 pm, David Powell wrote: > I've just posted PaceExtensionConstruct. As it is an extensibility > Pace, it would be good if we could schedule it for discussion with the > others. Me likey. Except: "The root element of the construct MUST have an attribute with the qualified name "atom:notation" and the value "structured"." Do you meant Q-name, or does it just have to be in the atom namespace? It looks like the former, which is not on. Secondly, I don't see the purpose of the attribute at all. "The element MAY contain either unstructured text, or be empty." This appears to exclude dates in a standard format. "tuple" This is not a real word. Graham --Apple-Mail-3-569132508 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 9w0BCQUxDxcNMDUwMTEzMDA1NzQ3WjAjBgkqhkiG9w0BCQQxFgQUV8TAYV9/FR0rUrhZdUnadO55 vu4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAVDjPh3tz3cU5ZwWDql6XM1Hf gPgUWMT9yERmfWYxFo0Z7wQ43UjRpf67bbjpPK58k9LzJDxi6Bmdf3rptwum+W8IAdDP5A1Qlrht Fl1jOtp1D//bvHp8n3+na5PMjHPuUXEjAXDymvNuqmPCCW3d30uy8/xUTJqStZyzh0QDae4djrTD 8XFAS3hMZLDzb3L7CawnrghajLMiy2lcpwzK05r4MeoKsKTqqxQy6VMA/0mldZhm3KrBCzflrJse rC24HGG3ky0rc8TDiqT0GXdu/BuJIwT9G5GyC6XoesEcNNE+Za5epJFbMuxz9MDqTV3KrseZmlqH 0gPomqLryCGSKgAAAAAAAA== --Apple-Mail-3-569132508-- From owner-atom-syntax@mail.imc.org Wed Jan 12 20: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 UAA06753 for ; Wed, 12 Jan 2005 20: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 j0D1B7K3052408; Wed, 12 Jan 2005 17:11: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 j0D1B7eR052407; Wed, 12 Jan 2005 17:11:07 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0D1B6CG052319 for ; Wed, 12 Jan 2005 17:11:07 -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 <20050113011106.MPRQ24912.mta05-winn.mailhost.ntl.com@aamta07-winn.mailhost.ntl.com>; Thu, 13 Jan 2005 01:11:06 +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 <20050113011106.ZEFW8064.aamta07-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Thu, 13 Jan 2005 01:11:06 +0000 Date: Thu, 13 Jan 2005 01:11:04 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <1582452042.20050113011104@djpowell.net> To: Robert Sayre CC: atom-syntax@imc.org Subject: Re: Posted PaceExtensionConstruct In-Reply-To: <41E5C596.1040708@franklinmint.fm> References: <1113271276.20050112211950@djpowell.net> <41E5BFEC.7000502@franklinmint.fm> <232817669.20050113004124@djpowell.net> <41E5C596.1040708@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 Thursday, January 13, 2005, 12:49:26 AM, you wrote: > I'm not sure why you would have two different mappings. Wouldn't it just > be an XML property every time? Not sure what you mean by an "XML property" - do you mean the contents of the element escaped and included as a string? (like rdf:parseType="Literal") >>There can be multiple Person constructs per entry though. One author, >>plus several contributors. > Right, what's the use case? FOAF doesn't need to be contained by > atom:person. Again, I'm not up for banning it, just making it undefined. But how would you know which of the Person constructs each foaf:Agent corresponded to? We don't have any atom:id element for Person constructs? -- Dave From owner-atom-syntax@mail.imc.org Wed Jan 12 20:39: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 UAA07857 for ; Wed, 12 Jan 2005 20:39: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 j0D1SFod074361; Wed, 12 Jan 2005 17:28: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 j0D1SFfB074359; Wed, 12 Jan 2005 17:28:15 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0D1SE21074089 for ; Wed, 12 Jan 2005 17:28:15 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta03-winn.mailhost.ntl.com ([212.250.162.8]) by mta10-winn.mailhost.ntl.com with ESMTP id <20050113012814.SLQE15581.mta10-winn.mailhost.ntl.com@aamta03-winn.mailhost.ntl.com>; Thu, 13 Jan 2005 01:28:14 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta03-winn.mailhost.ntl.com with ESMTP id <20050113012814.ZEUN9818.aamta03-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Thu, 13 Jan 2005 01:28:14 +0000 Date: Thu, 13 Jan 2005 01:28:12 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <7010540965.20050113012812@djpowell.net> To: Graham CC: atom-syntax@imc.org Subject: Re: Posted PaceExtensionConstruct In-Reply-To: <244067D8-64FE-11D9-8584-000A95DC3D90@mac.com> References: <1113271276.20050112211950@djpowell.net> <244067D8-64FE-11D9-8584-000A95DC3D90@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 Thursday, January 13, 2005, 12:57:47 AM, you wrote: > On 12 Jan 2005, at 9:19 pm, David Powell wrote: >> I've just posted PaceExtensionConstruct. As it is an extensibility >> Pace, it would be good if we could schedule it for discussion with the >> others. > Me likey. Except: > "The root element of the construct MUST have an attribute with the > qualified name "atom:notation" and the value "structured"." > Do you meant Q-name, or does it just have to be in the atom namespace? > It looks like the former, which is not on. I'm glad someone mentioned that. The attribute is supposed to be explicitly qualified with the atom namespace. This is because it will be inside a non-atom element, and I don't think we should define the meaning of un-namespaced attributes in non-atom elements. Note that this example is wrong: ... ... This appears to exclude dates in a standard format. Not intended, I think I mean PCDATA. > "tuple" > This is not a real word. OK, I'll reword it. -- Dave From owner-atom-syntax@mail.imc.org Wed Jan 12 20:41: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 UAA08065 for ; Wed, 12 Jan 2005 20:41: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 j0D1ZRC5082934; Wed, 12 Jan 2005 17:35: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 j0D1ZRIa082933; Wed, 12 Jan 2005 17:35: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 ([161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0D1ZQxJ082687 for ; Wed, 12 Jan 2005 17:35:26 -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 j0D1YPhE017387; Thu, 13 Jan 2005 01:34:31 GMT In-Reply-To: <7010540965.20050113012812@djpowell.net> References: <1113271276.20050112211950@djpowell.net> <244067D8-64FE-11D9-8584-000A95DC3D90@mac.com> <7010540965.20050113012812@djpowell.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-571329952; protocol="application/pkcs7-signature" Message-Id: <4207AC7C-6503-11D9-8584-000A95DC3D90@mac.com> Cc: atom-syntax@imc.org From: Graham Subject: Re: Posted PaceExtensionConstruct Date: Thu, 13 Jan 2005 01:34:24 +0000 To: David Powell X-Mailer: Apple Mail (2.619) 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-571329952 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 13 Jan 2005, at 1:28 am, David Powell wrote: > It needs to be like this: (because namespace defaults don't apply to > attributes.) > > > ... > > ... Graham --Apple-Mail-4-571329952 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 9w0BCQUxDxcNMDUwMTEzMDEzNDI1WjAjBgkqhkiG9w0BCQQxFgQU4a3F7WJQxZqaCc5Rgy7NFqHp m00weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAxH1guMKeax62KSG0nQK+iRPh VU0Gbp9O5b95MSYnxtgNf6hK2y0c3D1/rGQymHl/ZQWsbLfE/eAdL5lGmZobFLAQ9xnpoAAA/ONu rHdjaqxj8Zz15nldWsuhjaUv4Jfj/y5Lpxkpv6ozG8iUck6QFQm1DVx/vD1/CnHXfPvZDCef1yHF ANurJyAYtQLyVJFq+vCkJnkMNrjtQzB/jW7FBwrkF+eyx4hO4SweW40tO3NeYlCuflhvc7W8MXkH MMEmoILK8c0o9jJFXi/xlLmXKazqXUbqnDtUYn0LKn/r09KfFQVsaTKPAE4YquYX2PD5BdSs8XVn HpunuA+T/woHYgAAAAAAAA== --Apple-Mail-4-571329952-- From owner-atom-syntax@mail.imc.org Wed Jan 12 21:52: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 VAA12276 for ; Wed, 12 Jan 2005 21: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 j0D2i3WU026214; Wed, 12 Jan 2005 18:44: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 j0D2i35e026213; Wed, 12 Jan 2005 18:44: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 j0D2i2c5026193 for ; Wed, 12 Jan 2005 18:44: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 j0D2gmE7029778; Thu, 13 Jan 2005 02:42:54 GMT In-Reply-To: <41E5DF48.80005@intertwingly.net> References: <951094EE-64F6-11D9-AC31-003065EA6144@geckotribe.com> <41E5DF48.80005@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-575434897; protocol="application/pkcs7-signature" Message-Id: Cc: atom-syntax@imc.org From: Graham Subject: Re: Questions about -04 Date: Thu, 13 Jan 2005 02:42:49 +0000 To: Sam Ruby X-Mailer: Apple Mail (2.619) 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-575434897 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 13 Jan 2005, at 2:39 am, Sam Ruby wrote: > Every version of RSS has this as a mandatory element. Every last one > of them. Except RSS 2.0: "An item may also be complete in itself, if so, the description contains the text (entity-encoded HTML is allowed; see examples), and the link and title may be omitted" Graham --Apple-Mail-5-575434897 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 9w0BCQUxDxcNMDUwMTEzMDI0MjUwWjAjBgkqhkiG9w0BCQQxFgQUcLYDvGTDqZQDgvSFmJ7iDuFd xskweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAlbeVHZlx9E4sXQAVRMv0W/D3 GeG4HHXVh2fgJhKWQAwO/Ypk02Lqcx2kPyZb+bJ5TG7mV20K+faKCTvqlJD26yyYAYBY1cQaa8gz Mc6yjeNCW7QpIji/G1bor29V5wtivdsgdgFw1Z/ufQaP6+qfyrxx8ytdC5RYTvG1lEDuUXXcEDjA UUpsjK+BC4OnNkOujPAK8L5csXRO0PHHHByeHSVsxTWy6tU4vYHYPrLzczEsxBOr5qcvhn+4UxbS A7EkgbA/Ep/OEkSSEVLir4zS8SkflzLRJJCoW0krwPeEXYTqG+OqnNSrZcOTbcRsf6MPPtNMu1w9 8YlgX32E0WK1pAAAAAAAAA== --Apple-Mail-5-575434897-- From owner-atom-syntax@mail.imc.org Wed Jan 12 21:52: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 VAA12309 for ; Wed, 12 Jan 2005 21:52: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 j0D2d9jv025751; Wed, 12 Jan 2005 18: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 j0D2d9IW025750; Wed, 12 Jan 2005 18:39:09 -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 j0D2d3g1025740 for ; Wed, 12 Jan 2005 18:39:08 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.110] (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 j0D2d7kc000004; Wed, 12 Jan 2005 21:39:07 -0500 (EST) Message-ID: <41E5DF48.80005@intertwingly.net> Date: Wed, 12 Jan 2005 21:39:04 -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@imc.org Subject: Re: Questions about -04 References: <951094EE-64F6-11D9-AC31-003065EA6144@geckotribe.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 Graham wrote: > On 13 Jan 2005, at 12:03 am, Antone Roundy wrote: > >>> Every piece of running code, for all versions of RSS and Atom, expect >>> this data to be present. >>> >> ...except CaRP and Grouper. Any others? > > Shrook and NetNewsWire? > > I believe Sam needs to go sit in the corner until he's learnt his > lesson. Bad Sam. Every version of RSS has this as a mandatory element. Every last one of them. - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Jan 12 22:03: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 WAA12773 for ; Wed, 12 Jan 2005 22:03: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 j0D2uIwM029044; Wed, 12 Jan 2005 18:56: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 j0D2uHrr029041; Wed, 12 Jan 2005 18:56:17 -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 j0D2uH8g029033 for ; Wed, 12 Jan 2005 18:56:17 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.110] (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 j0D2uKCh025747; Wed, 12 Jan 2005 21:56:21 -0500 (EST) Message-ID: <41E5E353.7050900@intertwingly.net> Date: Wed, 12 Jan 2005 21:56: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: Graham CC: atom-syntax@imc.org Subject: Re: Questions about -04 References: <951094EE-64F6-11D9-AC31-003065EA6144@geckotribe.com> <41E5DF48.80005@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 13 Jan 2005, at 2:39 am, Sam Ruby wrote: > >> Every version of RSS has this as a mandatory element. Every last one >> of them. > > Except RSS 2.0: > "An item may also be complete in itself, if so, the description contains > the text (entity-encoded HTML is allowed; see examples), and the link > and title may be omitted" Restoring the portion that you excerpted away: > 2. Why MUST a feed point to an alternate version. What if the feed is all > I publish? http://blogs.law.harvard.edu/tech/rss#requiredChannelElements - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Jan 12 22:16: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 WAA13714 for ; Wed, 12 Jan 2005 22: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 j0D3AaJk030790; Wed, 12 Jan 2005 19:10: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 j0D3AaE6030789; Wed, 12 Jan 2005 19:10:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [69.20.61.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0D3AZlE030783 for ; Wed, 12 Jan 2005 19:10:36 -0800 (PST) (envelope-from brent@ranchero.com) Received: from [192.168.0.3] (c-67-171-27-118.client.comcast.net [67.171.27.118]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.10) with ESMTP id j0D3AfgV011278 for ; Wed, 12 Jan 2005 22:10:41 -0500 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <951094EE-64F6-11D9-AC31-003065EA6144@geckotribe.com> <41E5DF48.80005@intertwingly.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Brent Simmons Subject: Re: Questions about -04 Date: Wed, 12 Jan 2005 19:10:36 -0800 To: atom-syntax@imc.org X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 12, 2005, at 6:42 PM, Graham wrote: > On 13 Jan 2005, at 2:39 am, Sam Ruby wrote: > >> Every version of RSS has this as a mandatory element. Every last one >> of them. > > Except RSS 2.0: > "An item may also be complete in itself, if so, the description > contains the text (entity-encoded HTML is allowed; see examples), and > the link and title may be omitted" > > Graham It's weird, but true, and I suspect that every aggregator author has already taken this into account. There are indeed RSS 2.0 feeds that don't have elements. An example is http://www.scripting.com/rss.xml I don't think it would be a hardship were atom:link to be optional, given the circumstances. I myself would probably prefer it be required, but only because aggregator users expect that items will have permalinks. -Brent From owner-atom-syntax@mail.imc.org Wed Jan 12 22: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 WAA14375 for ; Wed, 12 Jan 2005 22:25: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 j0D3JE1r031589; Wed, 12 Jan 2005 19:19: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 j0D3JEdN031588; Wed, 12 Jan 2005 19:19:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailgw.afc.gov.au (mail.afc.gov.au [203.202.130.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0D3JCxq031523 for ; Wed, 12 Jan 2005 19:19:13 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [192.168.25.2] (HELO afc.gov.au) by mailgw.afc.gov.au (CommuniGate Pro SMTP 4.2.7) with ESMTP id 1744198 for atom-syntax@imc.org; Thu, 13 Jan 2005 14:19:04 +1100 Received: from [192.168.25.1] (HELO [192.168.45.41]) by afc.gov.au (CommuniGate Pro SMTP 4.2.5) with ESMTP id 1810846 for atom-syntax@imc.org; Thu, 13 Jan 2005 14:19:04 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 13 Jan 2005 12:47:39 +1100 Subject: Re: Questions about -04 From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <951094EE-64F6-11D9-AC31-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 13/1/05 11:03 AM, "Antone Roundy" wrote: >>>>> 2. Why MUST a feed point to an alternate version. What if the feed >>>>> is all I publish? >>>> >>>> I'm -1 on removing this restriction. >>> >>> I'm +1 on removing it, and given the number of people who've >>> commented on it over the last year, I think you're outnumbered. >> >> Every piece of running code, for all versions of RSS and Atom, expect >> this data to be present. >> > ...except CaRP and Grouper. Any others? NetNewsWire does know how to handle if present, but it doesn't panic if it's missing. e. From owner-atom-syntax@mail.imc.org Wed Jan 12 23:07: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 XAA16883 for ; Wed, 12 Jan 2005 23:07: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 j0D3vAPN040867; Wed, 12 Jan 2005 19:57: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 j0D3vAnU040866; Wed, 12 Jan 2005 19:57: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 j0D3v92d040860 for ; Wed, 12 Jan 2005 19:57:10 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.9]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1Cow6F-0005QE-Eo; Thu, 13 Jan 2005 03:56:43 +0000 Message-ID: <41E5F18F.4080004@franklinmint.fm> Date: Wed, 12 Jan 2005 22:57:03 -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: Sam Ruby CC: Graham , atom-syntax@imc.org Subject: Re: Questions about -04 References: <951094EE-64F6-11D9-AC31-003065EA6144@geckotribe.com> <41E5DF48.80005@intertwingly.net> <41E5E353.7050900@intertwingly.net> In-Reply-To: <41E5E353.7050900@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: > > http://blogs.law.harvard.edu/tech/rss#requiredChannelElements OK, Sam has swayed me. If there are masses of publishers eager to do away with that restriction, they will. And someone will come back and change the spec to reflect reality. However, that link element often just points at a web page that vaguely relates to the origin of the feed. That seems ok to me, in the absence of a better alternate. Remember folks, this is about feed-level links, not entries. Links in entries are allowed to be omitted if there's atom:content (PaceContentOrLink, format-04). Robert Sayre From owner-atom-syntax@mail.imc.org Thu Jan 13 04: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 EAA19094 for ; Thu, 13 Jan 2005 04:05: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 j0D8jJ1l013175; Thu, 13 Jan 2005 00:45: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 j0D8jJDO013174; Thu, 13 Jan 2005 00:45:19 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0D8jIBl013133 for ; Thu, 13 Jan 2005 00:45:18 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta07-winn.mailhost.ntl.com ([212.250.162.8]) by mta10-winn.mailhost.ntl.com with ESMTP id <20050113084512.WZCO15581.mta10-winn.mailhost.ntl.com@aamta07-winn.mailhost.ntl.com>; Thu, 13 Jan 2005 08:45:12 +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 <20050113084512.NBMA8064.aamta07-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Thu, 13 Jan 2005 08:45:12 +0000 Date: Thu, 13 Jan 2005 08:45:07 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <949293416.20050113084507@djpowell.net> To: Graham CC: atom-syntax@imc.org Subject: Re: Posted PaceExtensionConstruct In-Reply-To: <4207AC7C-6503-11D9-8584-000A95DC3D90@mac.com> References: <1113271276.20050112211950@djpowell.net> <244067D8-64FE-11D9-8584-000A95DC3D90@mac.com> <7010540965.20050113012812@djpowell.net> <4207AC7C-6503-11D9-8584-000A95DC3D90@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 Thursday, January 13, 2005, 1:34:24 AM, you wrote: > On 13 Jan 2005, at 1:28 am, David Powell wrote: >> It needs to be like this: (because namespace defaults don't apply to >> attributes.) >> >> >> ... >> >> ... > Note that the choice of any namespace prefix is arbitrary and not > semantically significant. > I actually prefer your wrong example: > ... I prefer it to look at, but I don't think we should be defining the meaning of un-namespaced attributes in somebody elses element. It seems more appropriate to use a namespaced attribute for this. -- Dave From owner-atom-syntax@mail.imc.org Thu Jan 13 04: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 EAA20632 for ; Thu, 13 Jan 2005 04:32: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 j0D9O5lU032762; Thu, 13 Jan 2005 01:24: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 j0D9O5KT032761; Thu, 13 Jan 2005 01:24:05 -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 j0D9O4XO032660 for ; Thu, 13 Jan 2005 01:24:04 -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 23C064EFEE; Thu, 13 Jan 2005 04:24:00 -0500 (EST) Message-Id: <6.0.0.20.2.20050113173049.072c56c0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 13 Jan 2005 17:35:56 +0900 To: Sam Ruby , Norman Walsh From: Martin Duerst Subject: Re: Questions about -04 Cc: Atom Syntax In-Reply-To: <41E59C93.4050001@intertwingly.net> References: <873bx6x1z1.fsf@nwalsh.com> <41E59C93.4050001@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 At 06:54 05/01/13, Sam Ruby wrote: > >Norman Walsh wrote: >> 2. Why MUST a feed point to an alternate version. What if the feed is all >> I publish? > >Deja vu: > >http://www.imc.org/atom-syntax/mail-archive/msg08836.html > >I'm -1 on removing this restriction. I don't see any clear justification in the above mail thread for having the restriction. And I think that in a very fundamental way, it's a mistake; feeds should be architected as independent technology, not as an adjunct to Web pages. For example, there is no restriction that every Web page has an email address (although such an address was on many Web pages (that was before spam)). Likewise, there is no restriction that every email or Web page point to a feed. Or that every chat channel has an associated feed or Web page. Integration of these communication media is extremely important, but forcing a link is not the right way to go. Regards, Martin. From owner-atom-syntax@mail.imc.org Thu Jan 13 04:59: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 EAA22182 for ; Thu, 13 Jan 2005 04:59: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 j0D9mg38056388; Thu, 13 Jan 2005 01:48: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 j0D9mftV056374; Thu, 13 Jan 2005 01:48:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0D9menZ056230 for ; Thu, 13 Jan 2005 01:48:40 -0800 (PST) (envelope-from lgonze@panix.com) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail1.panix.com (Postfix) with ESMTP id 4CE9158B38 for ; Thu, 13 Jan 2005 04:48:38 -0500 (EST) Received: from localhost (lgonze@localhost) by panix2.panix.com (8.11.6p3/8.8.8/PanixN1.1) with ESMTP id j0D9mc029297 for ; Thu, 13 Jan 2005 04:48:38 -0500 (EST) Date: Wed, 12 Jan 2005 23:48:38 -1000 (HST) From: Lucas Gonze Reply-To: lucas@gonze.com Cc: Atom Syntax Subject: Re: Questions about -04 In-Reply-To: <6.0.0.20.2.20050113173049.072c56c0@localhost> Message-ID: References: <873bx6x1z1.fsf@nwalsh.com> <41E59C93.4050001@intertwingly.net> <6.0.0.20.2.20050113173049.072c56c0@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 13 Jan 2005, Martin Duerst wrote: > I don't see any clear justification in the above mail thread > for having the restriction. And I think that in a very fundamental > way, it's a mistake; feeds should be architected as independent > technology, not as an adjunct to Web pages. I also see no reason for feeds to be shadows of web pages. The value of the link in the root element is to have a path towards the human or organizational source of a document. Return paths are useful but not a requirement on the web. From owner-atom-syntax@mail.imc.org Thu Jan 13 06:29: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 GAA28575 for ; Thu, 13 Jan 2005 06:29: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 j0DBDQmi092559; Thu, 13 Jan 2005 03:13: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 j0DBDQSs092558; Thu, 13 Jan 2005 03:13: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 j0DBDPQJ092511 for ; Thu, 13 Jan 2005 03:13:25 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so254484rnz for ; Thu, 13 Jan 2005 03:13:21 -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=k7U+6gTrCRuI64q5y6nU/ekJbZfPVtwPIm0mHqLP495ph19Q7ZJInvqV13Wo4/RVrfLrTE/ISbuzdJsbUTbukarGW5U/JIH1njQDn8+rGxvu3deDDbThMzHngihwJdymsDWK/3bEQgJVL2Hm7iwekK7XkCf+EudPF+ySeb1XEog= Received: by 10.38.19.34 with SMTP id 34mr131718rns; Thu, 13 Jan 2005 03:13:21 -0800 (PST) Received: by 10.38.179.71 with HTTP; Thu, 13 Jan 2005 03:13:21 -0800 (PST) Message-ID: <1f2ed5cd05011303136730fced@mail.gmail.com> Date: Thu, 13 Jan 2005 12:13:21 +0100 From: Danny Ayers Reply-To: Danny Ayers To: David Powell Subject: Re: Posted PaceExtensionConstruct Cc: atom-syntax@imc.org In-Reply-To: <949293416.20050113084507@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1113271276.20050112211950@djpowell.net> <244067D8-64FE-11D9-8584-000A95DC3D90@mac.com> <7010540965.20050113012812@djpowell.net> <4207AC7C-6503-11D9-8584-000A95DC3D90@mac.com> <949293416.20050113084507@djpowell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 13 Jan 2005 08:45:07 +0000, David Powell wrote: I very much like the general approach of this Pace, I reckon it's very close to what's needed. If there is some way to lose atom:notation without introducing ambiguity it would be better (if something is needed, what about atom:type as used on content - might that be a suitable replacement?) My feeling is that ideally it should be possible to deterministically transform Atom+extensions into an abstract model based on entities and relationships. Whether the target model is traditional E-R, UML, RDF, Topic Maps or whatever doesn't matter. From there it would be easy to see how specific profiles could be developed, without impacting the core - so Henry's RDF/OWL description of Atom could appear in an I-D as the RDF Profile of Atom. I think this could potentially be better than what's found with most profiling, not requiring additional constraints. There would be a guarantee that the output of *the* Atom2RDF XSLT would always be valid RDF/XML if the input was valid Atom(+extensions). (It would be nice later to have XSLT for Atom2UML, whatever Rational etc use - XMI? - that could be used to automatically create class libraries for arbitrary extensions). Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Jan 13 07:58: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 HAA04828 for ; Thu, 13 Jan 2005 07:58: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 j0DCgPum031218; Thu, 13 Jan 2005 04: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 j0DCgPpI031217; Thu, 13 Jan 2005 04:42:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxsf27.cluster1.charter.net (mxsf27.cluster1.charter.net [209.225.28.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DCgOmi031166 for ; Thu, 13 Jan 2005 04:42:24 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from mxip10.cluster1.charter.net (mxip10a.cluster1.charter.net [209.225.28.140]) by mxsf27.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id j0DCgHAv008791 for ; Thu, 13 Jan 2005 07:42:18 -0500 Received: from cpe-68-112-239-32.ma.charter.com (HELO localhost) (68.112.239.32) by mxip10.cluster1.charter.net with ESMTP; 13 Jan 2005 07:42:17 -0500 X-Ironport-AV: i="3.88,120,1102309200"; d="scan'208"; a="538271668:sNHT32566030" Received: from ndw by localhost with local (Exim 4.34) id 1Cp4Ik-0004NM-HA for atom-syntax@imc.org; Thu, 13 Jan 2005 07:42:10 -0500 To: Atom Syntax Subject: Re: Questions about -04 References: <873bx6x1z1.fsf@nwalsh.com> <41E59C93.4050001@intertwingly.net> From: Norman Walsh X-URL: http://nwalsh.com/ Date: Thu, 13 Jan 2005 07:42:02 -0500 In-Reply-To: <41E59C93.4050001@intertwingly.net> (Sam Ruby's message of "Wed, 12 Jan 2005 16:54:27 -0500") Message-ID: <87r7kp33hh.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 / Sam Ruby was heard to say: | Norman Walsh wrote: |> 2. Why MUST a feed point to an alternate version. What if the feed is all |> I publish? I feel I should say that I was just asking the question, I don't have a strong feeling one way or the other. My attention has been elsewhere for several months and I've missed a lot of the discussion. Apologies for causing old issues to be rehashed. Be seeing you, norm =2D-=20 Norman Walsh | Life always comes to a bad end.--Marcel http://nwalsh.com/ | Aym=C3=A9 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBB5myiOyltUcwYWjsRAr+6AJ450QoALRnx9PNlbcQFikNtMtwkcACcDeEf UZK9OygMpZyb91XURQzwzPI= =/C/r -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Thu Jan 13 08:01: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 IAA05150 for ; Thu, 13 Jan 2005 08:01: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 j0DCiCDd031896; Thu, 13 Jan 2005 04:44: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 j0DCiCU1031895; Thu, 13 Jan 2005 04:44:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxsf16.cluster1.charter.net (mxsf16.cluster1.charter.net [209.225.28.216]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DCiBcP031859 for ; Thu, 13 Jan 2005 04:44:11 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from mxip20.cluster1.charter.net (mxip20a.cluster1.charter.net [209.225.28.150]) by mxsf16.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id j0DCi7G9014339 for ; Thu, 13 Jan 2005 07:44:07 -0500 Received: from cpe-68-112-239-32.ma.charter.com (HELO localhost) (68.112.239.32) by mxip20.cluster1.charter.net with ESMTP; 13 Jan 2005 07:44:07 -0500 X-Ironport-AV: i="3.88,120,1102309200"; d="scan'208"; a="636467562:sNHT17364408" Received: from ndw by localhost with local (Exim 4.34) id 1Cp4KX-0004Nt-Ec for atom-syntax@imc.org; Thu, 13 Jan 2005 07:44:01 -0500 To: Atom Syntax Subject: Anybody started a test suite of valid/invalid feeds? From: Norman Walsh X-URL: http://nwalsh.com/ Date: Thu, 13 Jan 2005 07:44:01 -0500 Message-ID: <87k6qhpkha.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'd feel more confident about my RELAX NG grammar if I could feed more than my own two or three test cases through it. Be seeing you, norm =2D-=20 Norman Walsh | Great success is commoner than real http://nwalsh.com/ | abilities.-- Vauvenargues --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBB5m0ROyltUcwYWjsRApySAJ0bY+gQkNLQVH8y2iGme3tkzOU/fwCfY+7V sM0x3ZP8xEkFOiE74epUQu8= =BE76 -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Thu Jan 13 09:46: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 JAA15143 for ; Thu, 13 Jan 2005 09:46: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 j0DEW9U8005708; Thu, 13 Jan 2005 06: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 j0DEW9RB005707; Thu, 13 Jan 2005 06:32: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 j0DEW43E005570 for ; Thu, 13 Jan 2005 06:32:04 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 6396 invoked by uid 17064); 13 Jan 2005 14:31:34 -0000 Received: from unknown (HELO [192.168.0.7]) ([193.251.47.164]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 13 Jan 2005 14:31:34 -0000 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-owl@googlegroups.com, bloged From: Henry Story Subject: Re: xml without rdf, but with an ontology [0] Date: Thu, 13 Jan 2005 15:31:32 +0100 To: www-rdf-interest@w3.org, "'Atom WG'" X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray, Roy Fielding and other have recently made some interesting comments on the atom list saying that xml's tree structure has an implicit semantics. If this is the case then one should be able to map any xml into triple space graph. There is no special need for any special rdf/xml. So let me take the following example, a little extended version of the example from the current atom spec. Example Feed 2003-12-13T18:30:02Z BlogEd John Doe Atom-Powered Robots Run Amok vemmi://example.org/2003/32397 vemmi://example.org/2003/32397/v1 2003-12-13T18:30:02Z By following an nearly DOMish interpretation of the above we get the graph below _f -feed->_f1 |-head->_h1 | |-title--> _t1 | | |--xxx:string--> "example Feed" | |-link--->_l1 | | |--href-> _href1 | | |---xxx:string---v | | "http://example.org/" | |-updated->_up1 | | |-xxx:string-> "2003-12-13T18:30:02Z" | |--author-->_a1 | | |-name-> _nme | | | |-xxx:string-> "John Doe" | | |-mbox-> _mbox1 | | |-xxx:string->"john@doe.com" | |-generator-> _gen | |---uri--->_u1 | | |-----xxx:string-----v | | "https://bloged.dev.java.net/" | |-version-> _ver | | |--xxx:string-> "0.5" | |--xx:string-> "BlogEd" | |--entry-->_e1 |--title--> _t2 | |-xxx:string---v | "Atom Powered Robots Run Amok" |--link->_l1 | |-href-> _href2 | |----xxx:string---v | "http://example.org/2003/12/13/atom03" |-id-> _id | |-xxx:string--v | "vemmi://example.org/2003/12/13/atom03" |-versionid-> _vs1 | |----xxx:string------v | "vemmi://example.org/2003/12/13/atom03/v1" |--updated->_up |--xx:string-> "2003-12-13T18:30:02Z" So that is a graph. It is easy to see how a beginner DOM programmer could generate one such automatically. No magic there. And I think it nicely captures Tim Bray and Roy Fielding's intuition that xml nodes express properties on their parents. Now let us imagine we now have an ontology that contains the following statements for all S and O if S --title----> O then O -is a-> if S --link-----> O then O -is a-> if S --href-----> O then O -is a-> if S --updated--> O then O -is a-> if S --author---> O then O -is a-> if S --name-----> O then O -is a-> if S --mbox-----> O then O -is a-> if S --uri------> O then O -is a-> if S --version--> O then O -is a-> if S --entry----> O then O -is a-> if S --title----> O then O -is a-> if S --link-----> O then O -is a-> if S --name-----> O then O -is a-> if S --id-------> O then O -is a-> if S -versionId-> O then O -is a-> if S --updated--> O then O -is a-> With the above facts we can then update our graph like this (I have not added all the consequences to keep the graph readable) _f -feed->_f1 |-head->_h1 | |-title--> _t1 ==is=a==> | | |--xxx:string--> "example Feed" | | | |-link--->_l1 | | |--href-> _href1 ==is=a=> | | |-xxx:string-> "http://example.org/" | | | |-updated->_up1 ==is=a=> | | |-xxx:string-> "2003-12-13T18:30:02Z" | | | |--author-->_a1 | | |-name-> _nme ==is=a==> | | | |-xxx:string-> "John Doe" | | | | | |-mbox-> _mbox1 ==is=a==> | | |-xxx:string->"john@doe.com" | |-generator-> _gen | |---uri--->_u1 ==is=a=> | | |-----xxx:string----v | | "https://bloged.dev.java.net/" | |-version-> _ver ==is=a=> | | |--xxx:string-> "0.5" | |--xx:string-> "BlogEd" | |--entry-->_e1 |--title--> _t2 ==is=a==> | |-xxx:string--v | "Atom Powered Robots Run Amok" | |--link->_l1 | |-href-> _href2 ==is=a=> | |-xxx:string--v | "http://example.org/2003/12/13/atom03" | |-id-> _id ==is=a=> | |-xxx:string--v | "vemmi://example.org/2003/12/13/atom03" | |-versionid-> _vs1 ==is=a=> | |-------xxx:string------v | "vemmi://example.org/2003/12/13/atom03/v1" | |--updated->_up ==is=a=> |--xx:string-> "2003-12-13T18:30:02Z" Still no magic. So next we assume that the ontology contains a graph transformation rule that allows the following transformation from S -----is a--> |-xxx:string-> "some string here" to "some string here" ie: S == "some string here" and from S -----is a--> |-xxx:string-> "http://bblfish.net/" to ie: S == From the above rules our graph now becomes _f -feed->_f1 |-head->_h1 | |-title--> "example Feed" | | | |-link--->_l1 | | |--href-> | | | |-updated->_up1 -is-a-> | | |-xxx:string-> "2003-12-13T18:30:02Z" | | | |--author-->_a1 | | |-name->"John Doe" | | |-mbox-> "john@doe.com" | |-generator-> _gen | |---uri---v | | | |-version-> "0.5" | |--xx:string-> "BlogEd" | |--entry-->_e1 |--title--> "Atom Powered Robots Run Amok" | |--link->_l1 | |--------href----v | | |-id-> | |---------------versionid------v | | |--updated->_up -is-a-> |--xx:string-> "2003-12-13T18:30:02Z" The above graph is just a consequence of applying those rules. We could have other rules such as the versionid property is functional, inverse functional, symmetric and transitive ie: if S --versionid--> O then S == O This would give us the following graph _f -feed->_f1 |-head->_h1 | |-title--> "example Feed" | |-link--->_l1 | | |--href-> | | | |-updated->_up1 -is-a-> | | |-xxx:string-> "2003-12-13T18:30:02Z" | | | |--author-->_a1 | | |-name->"John Doe" | | |-mbox-> "john@doe.com" | |-generator-> _gen | |-----------uri---v | | | |-version-> "0.5" | |--xx:string-> "BlogEd" | |--entry--> |--title--> "Atom Powered Robots Run Amok" | |--link->_l1 | |-----href---v | | |-id-> | |--updated->_up -is-a-> |--xx:string-> "2003-12-13T18:30:02Z" Interestingly enough the graph above I get is (nearly) exactly the same as the triple model I get from parsing the closest rdf/xml I could get that resembles the atom example xml: Example Feed 2003-12-13T18:30:02Z John Doe Atom-Powered Robots Run Amok vemmi://example.org/2003/32397 vemmi://example.org/2003/32397 2003-12-13T18:30:02Z So that would tend to indicate that we are close to the intuitions of the original developers of rdf/xml. But it looks like we don't need the special syntax of rdf/xml with the rdf:parseType thinggy. Any xml can be mapped to a graph following the rules implicit in the example given above. Having an ontology for the entities in that appear in the xml allows one to do graph transformations and reasoning. An ontology for the entities is all that is therefore required to make use of the 1rst level graph, and make it possible to understand what types of extensions to the xml are allowable. [1] Am I on the right track here? Henry Story [0] My internet connection was down this morning, during which time I wrote this, before being able to read the responses to my previous mail on the rdf interest and atom-owl list entitled "a simpler form of xml". This e-mail just works on the previous thought but is much clearer I think. For those readers on atom-owl and bloged I have fixed the ascii graphs in this version. [1] I could develop that in another email, if people are interested From owner-atom-syntax@mail.imc.org Thu Jan 13 10: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 KAA16547 for ; Thu, 13 Jan 2005 10: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 j0DEu3P9023135; Thu, 13 Jan 2005 06:56: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 j0DEu3lj023134; Thu, 13 Jan 2005 06:56:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DEu32R023090 for ; Thu, 13 Jan 2005 06:56:03 -0800 (PST) (envelope-from brett.lindsley@labs.mot.com) Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j0DF1qpL003642 for ; Thu, 13 Jan 2005 08:01:52 -0700 (MST) Received: from labs.mot.com (udomsvc2.labs.mot.com [173.23.250.2]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id j0DEr4ea002387 for ; Thu, 13 Jan 2005 08:53:05 -0600 Received: from udomsvc5.labs.mot.com (udomsvc5.labs.mot.com [173.23.250.5]) by labs.mot.com (MotLabs Smoke & Mirrors) with ESMTP id j0DEu1tv008848 for ; Thu, 13 Jan 2005 08:56:01 -0600 (CST) Received: from labs.mot.com by ims1.labs.mot.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0IA9008UVG5D53@ims1.labs.mot.com> for atom-syntax@imc.org; Thu, 13 Jan 2005 08:56:01 -0600 (CST) Date: Thu, 13 Jan 2005 08:56:01 -0600 From: Brett Lindsley Subject: Head:id vs entry:id Cc: Atom Syntax Message-id: <41E68C01.1050409@labs.mot.com> Organization: Mot Labs MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <41781245.30207@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT This may be an obvious question and I may have missed something in the discussion, but can someone clarify why the head:id is optional (MAY) whereas the entry:id is required (MUST)? Having a unique way to identify a feed may be useful to associate a group of entries (with "heads in entries") obtained from a variety of sources. Another use may be to determine if a particular entry (again with the head in the entry) belongs to a particular subscription. Please advise. Brett Lindsley, Motorola Labs From owner-atom-syntax@mail.imc.org Thu Jan 13 10:26: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 KAA18874 for ; Thu, 13 Jan 2005 10:26: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 j0DFChpo041901; Thu, 13 Jan 2005 07:12: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 j0DFChXQ041900; Thu, 13 Jan 2005 07:12:43 -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 j0DFCgb4041840 for ; Thu, 13 Jan 2005 07:12:42 -0800 (PST) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so113017wra for ; Thu, 13 Jan 2005 07:12: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:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=EqWc11bHGIjcSZ9FbIOKqAdB7gdXI6f1NKuzqQJW+Y1znoz/82KQw9Y1ITjpeiz7f7YiyCCfmDUZniP0zZqcDkGRGq792txufPsYYq853O9EkpXJA7Dw9EGJTmUbprO/L9RD0yPV3U66mGA98Dybw/y7d1kOIri7njQ3g/gniOg= Received: by 10.54.50.59 with SMTP id x59mr280415wrx; Thu, 13 Jan 2005 07:12:39 -0800 (PST) Received: by 10.54.18.2 with HTTP; Thu, 13 Jan 2005 07:12:39 -0800 (PST) Message-ID: <540e373205011307123fc474e1@mail.gmail.com> Date: Thu, 13 Jan 2005 09:12:39 -0600 From: "Roger B." Reply-To: "Roger B." To: atom-syntax@imc.org Subject: Re: PaceMinimalEntryVersioning 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'm in favor of this--it's easy enough to imagine uses for it (like a > feed showing the history of a particular entry). Antone: I'm +0 about it, but it might be a good idea to include some pointed warnings for publishers. Some client apps are going to use the first entry in the feed, some the last... some will look at dates, some won't... and so on. As with many of these "someone might need it some day" proposals, multiple instances of an atom:id in a feed will mean the user experience goes from the standard "variable" to "wholly unpredictable". That means complaints sent to the client author, who then has the unenviable task of saying, "Look, the person who threw this feed together is following the spec, but so am I. Sucks to be you." Actually, I think I'll shut up now. The more I type, the closer I am to -1. -- Roger Benningfield. From owner-atom-syntax@mail.imc.org Thu Jan 13 11:05: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 LAA22018 for ; Thu, 13 Jan 2005 11:05: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 j0DFpHt3070173; Thu, 13 Jan 2005 07:51: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 j0DFpHgA070172; Thu, 13 Jan 2005 07:51:17 -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 j0DFpFT8070116 for ; Thu, 13 Jan 2005 07:51:16 -0800 (PST) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so123504wra for ; Thu, 13 Jan 2005 07:51: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:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=uoimkiMTDI108UqeNX/Is2+vnhR+yl4nQgzxwTPN4zrLpToi2IuBZkx7MpAU5RX1Rhx2An7o/ygHL7/FlSrU7t/RDro5Tu6+s4vlunQsn2d4HK5/sJ36X5/y0KhcQlPEBhIbmcCVlT1k8MX6dowdn4i0iMufUWcLigOX1Vjmffc= Received: by 10.54.10.3 with SMTP id 3mr52638wrj; Thu, 13 Jan 2005 07:51:11 -0800 (PST) Received: by 10.54.18.2 with HTTP; Thu, 13 Jan 2005 07:51:11 -0800 (PST) Message-ID: <540e3732050113075169a46450@mail.gmail.com> Date: Thu, 13 Jan 2005 09:51:11 -0600 From: "Roger B." Reply-To: "Roger B." To: atom-syntax@imc.org Subject: Re: PaceMustUnderstandElement In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4D78DC0A-64F1-11D9-AC31-003065EA6144@geckotribe.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > the > cost must be kept very near zero. Tim: Agreed, although I'm not sure that's possible. Right now, if someone subscribes to a feed and gets nothing, I can say "Look, the publisher is producing ill-formed XML/invalid Atom/etc." and leave it at that. I've got a legitimate finger to point. But atom:must-understand drops my resources and design objectives directly into the hands of every A-lister in the blogosphere. They can effectively demand that I support whatever they want me to support. I sympathize with those who have harmless uses for this sort of thing, but I really don't want to face the inevitable Atomic soup nazis. Definite -1. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Thu Jan 13 11:14: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 LAA22703 for ; Thu, 13 Jan 2005 11:14: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 j0DG2n5n078139; Thu, 13 Jan 2005 08: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 j0DG2nat078138; Thu, 13 Jan 2005 08:02:49 -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 j0DG2mFt078129 for ; Thu, 13 Jan 2005 08:02:48 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.110] (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 j0DG2lCh008475; Thu, 13 Jan 2005 11:02:47 -0500 (EST) Message-ID: <41E69BA5.6030505@intertwingly.net> Date: Thu, 13 Jan 2005 11:02:45 -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: Anybody started a test suite of valid/invalid feeds? References: <87k6qhpkha.fsf@nwalsh.com> In-Reply-To: <87k6qhpkha.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: > I'd feel more confident about my RELAX NG grammar if I could feed > more than my own two or three test cases through it. What we have is here: http://intertwingly.net/wiki/pie/ConformanceTests If anybody knows of more, please add it to the list. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Jan 13 13:23: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 NAA00962 for ; Thu, 13 Jan 2005 13:23: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 j0DI9Hnn052126; Thu, 13 Jan 2005 10:09: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 j0DI9H0I052125; Thu, 13 Jan 2005 10:09: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.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DI9HTB052091 for ; Thu, 13 Jan 2005 10:09:17 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 1so1040628rny for ; Thu, 13 Jan 2005 10:09: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:mime-version:content-type:content-transfer-encoding; b=taoXJrvQ9K+9LSXvXp+WcUTVYELfMUyvu3BmGcRew4pfomSm37gUDGkmBiR7tP6nLJdxDrqXwLGAmUO20ejryjwwsJACrAhrvVSKkjMoqSSLxxebFhfajDFJHF/TGN3eYqQbEjk2Ny/PJtpxYmbkz79sI0eg5sjTlGCWvyn69SI= Received: by 10.38.8.12 with SMTP id 12mr270478rnh; Thu, 13 Jan 2005 10:09:13 -0800 (PST) Received: by 10.38.179.71 with HTTP; Thu, 13 Jan 2005 10:09:13 -0800 (PST) Message-ID: <1f2ed5cd0501131009ef1b954@mail.gmail.com> Date: Thu, 13 Jan 2005 19:09:13 +0100 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: Top 100s 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 fyi, Dare has blogged on "Syndicating Ordered Lists" pointing to Netflix's rather thin RSS 2.0 feed, pointing to some holes in the format(s). I know this scenario came up a while back somewhere around 'order', I'm not really sure how well covered it is now (or needs to be). http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=a257ba40-b9fd-4cba-959a-2bba6ae917f0 Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Jan 13 14:32: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 OAA06446 for ; Thu, 13 Jan 2005 14:32: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 j0DJLxDC004138; Thu, 13 Jan 2005 11:21: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 j0DJLxER004136; Thu, 13 Jan 2005 11:21:59 -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 j0DJLw87004113 for ; Thu, 13 Jan 2005 11:21:58 -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 j0DJLwVu010739 for ; Thu, 13 Jan 2005 12:21:58 -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 <0IA900JTISGM0W@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 13 Jan 2005 12:21:58 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA9000KJSFT7R@mail.sun.net> for atom-syntax@imc.org; Thu, 13 Jan 2005 12:21:58 -0700 (MST) Date: Thu, 13 Jan 2005 10:28:44 -0800 From: Tim Bray Subject: PaceExtensibilityAndVersioning 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 -0 I could live with this, but I think PaceMustUnderstandElement buys 80% of the benefit with 20% of the cost/apparatus. -Tim From owner-atom-syntax@mail.imc.org Thu Jan 13 14:32: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 OAA06447 for ; Thu, 13 Jan 2005 14:32: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 j0DJLklf004018; Thu, 13 Jan 2005 11:21: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 j0DJLkRv004017; Thu, 13 Jan 2005 11:21: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-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 j0DJLj4u004009 for ; Thu, 13 Jan 2005 11:21: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 j0DJLjVu010581 for ; Thu, 13 Jan 2005 12:21:45 -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 <0IA900JUZSG9GX@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 13 Jan 2005 12:21:45 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA9000KJSFT7R@mail.sun.net> for atom-syntax@imc.org; Thu, 13 Jan 2005 12:21:45 -0700 (MST) Date: Thu, 13 Jan 2005 10:44:33 -0800 From: Tim Bray Subject: PacePropertyDesign To: Atom Syntax Message-id: <2AB3BED2-6593-11D9-9616-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 This one shouldn't, in my opinion, be on our active-discussion queue, because it's uncooked. That is to say, it doesn't actually propose specific changes to our format or protocol drafts. Having said that, the thinking seems usefully clean and minimal, and I wouldn't be surprised if a real Pace, including proposed draft revisions, could be built out of this that would have a chance at consensus. But having said that, the language is crucial. For example, I would be -1 on any change that requires Atom implementors to have to internalize the notions of "RDF XML Literal" or, really, having to understand http://www.w3.org/1999/02/22-rdf-syntax-ns, which is referenced by the Pace. Also, it seems like there's a missing piece. I'm pretty sure that if we did it this way, it would be pretty easy to do a canonical and simple mapping from Atom to RDF/XML (right?), and if so, someone should write an I-D to define this, and I'd be in favor of adopting it as a WG draft. -Tim From owner-atom-syntax@mail.imc.org Thu Jan 13 14:32: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 OAA06531 for ; Thu, 13 Jan 2005 14:32: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 j0DJLoOT004067; Thu, 13 Jan 2005 11: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 j0DJLocs004066; Thu, 13 Jan 2005 11:21:50 -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 j0DJLn6I004052 for ; Thu, 13 Jan 2005 11:21:49 -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 j0DJLndt016604 for ; Thu, 13 Jan 2005 12:21:49 -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 <0IA900JSMSGD0W@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 13 Jan 2005 12:21:49 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA9000KJSFT7R@mail.sun.net> for atom-syntax@imc.org; Thu, 13 Jan 2005 12:21:49 -0700 (MST) Date: Thu, 13 Jan 2005 10:32:57 -0800 From: Tim Bray Subject: PaceMinimalEntryVersioning To: Atom Syntax Message-id: <8BC6F4B0-6591-11D9-9616-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 -1 I think this issue has been discussed to death and the current consensus around atom:id and atom:updated will meet users' needs simply and elegantly. Trying to achieve consensus on a generalized abstract model of versioning is doomed to failure. -Tim From owner-atom-syntax@mail.imc.org Thu Jan 13 14:33: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 OAA06557 for ; Thu, 13 Jan 2005 14:33: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 j0DJMCxs004172; Thu, 13 Jan 2005 11:22: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 j0DJMCKl004171; Thu, 13 Jan 2005 11:22: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-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 j0DJM7I9004160 for ; Thu, 13 Jan 2005 11:22:11 -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 j0DJM7Vu010869 for ; Thu, 13 Jan 2005 12:22:07 -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 <0IA900HI3SGUMO@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 13 Jan 2005 12:22:06 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA9000KJSFT7R@mail.sun.net> for atom-syntax@imc.org; Thu, 13 Jan 2005 12:22:06 -0700 (MST) Date: Thu, 13 Jan 2005 10:27:43 -0800 From: Tim Bray Subject: PaceExtendingAtom 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 +1 I wrote it and I still think it's necessary as a bare-minimum measure. -Tim From owner-atom-syntax@mail.imc.org Thu Jan 13 14:33: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 OAA06581 for ; Thu, 13 Jan 2005 14:33: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 j0DJLjVe004004; Thu, 13 Jan 2005 11:21: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 j0DJLjur003995; Thu, 13 Jan 2005 11:21: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-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 j0DJLhEE003980 for ; Thu, 13 Jan 2005 11:21: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 j0DJLhdt016525 for ; Thu, 13 Jan 2005 12:21:43 -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 <0IA900JRXSG70W@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 13 Jan 2005 12:21:43 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA9000KJSFT7R@mail.sun.net> for atom-syntax@imc.org; Thu, 13 Jan 2005 12:21:43 -0700 (MST) Date: Thu, 13 Jan 2005 10:46:30 -0800 From: Tim Bray Subject: PaceAltExtensibilityAndVersioning To: Atom Syntax Message-id: <7082CAB6-6593-11D9-9616-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 -1 I think we can and should do without a version number. -Tim From owner-atom-syntax@mail.imc.org Thu Jan 13 14:33: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 OAA06620 for ; Thu, 13 Jan 2005 14:33: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 j0DJLj0O004003; Thu, 13 Jan 2005 11:21: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 j0DJLj0d004002; Thu, 13 Jan 2005 11:21: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 j0DJLioM003987 for ; Thu, 13 Jan 2005 11:21: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 j0DJLiVu010533 for ; Thu, 13 Jan 2005 12:21: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 <0IA900JRXSG70W@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 13 Jan 2005 12:21:43 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA9000KJSFT7R@mail.sun.net> for atom-syntax@imc.org; Thu, 13 Jan 2005 12:21:43 -0700 (MST) Date: Thu, 13 Jan 2005 10:46:00 -0800 From: Tim Bray Subject: PaceSupersede To: Atom Syntax Message-id: <5ED81998-6593-11D9-9616-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 -1 There are as many notions of versioning in the world as there are applications in the world, and "supersedes" model, while not that untypical, is far from universal. It doesn't deserve to get special treatment in Atom core. -Tim From owner-atom-syntax@mail.imc.org Thu Jan 13 14:33: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 OAA06638 for ; Thu, 13 Jan 2005 14:33: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 j0DJLqt8004090; Thu, 13 Jan 2005 11: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 j0DJLq8k004089; Thu, 13 Jan 2005 11:21:52 -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 j0DJLpMp004080 for ; Thu, 13 Jan 2005 11:21:51 -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 j0DJLpdt016618 for ; Thu, 13 Jan 2005 12:21: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 <0IA900JSZSGF0W@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 13 Jan 2005 12:21:51 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA9000KJSFT7R@mail.sun.net> for atom-syntax@imc.org; Thu, 13 Jan 2005 12:21:50 -0700 (MST) Date: Thu, 13 Jan 2005 10:31:08 -0800 From: Tim Bray Subject: PaceExtensionNamespace To: Atom Syntax Message-id: <4AF451E8-6591-11D9-9616-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 -1 Way too complex, feels like a negative return on the complexity/benefit trade-off. -Tim From owner-atom-syntax@mail.imc.org Thu Jan 13 14:34: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 OAA06683 for ; Thu, 13 Jan 2005 14:34: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 j0DJLroU004104; Thu, 13 Jan 2005 11:21: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 j0DJLrhn004102; Thu, 13 Jan 2005 11:21: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-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 j0DJLqEi004086 for ; Thu, 13 Jan 2005 11:21:52 -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 j0DJLpVu010659 for ; Thu, 13 Jan 2005 12:21: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 <0IA900JSZSGF0W@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 13 Jan 2005 12:21:51 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA9000KJSFT7R@mail.sun.net> for atom-syntax@imc.org; Thu, 13 Jan 2005 12:21:51 -0700 (MST) Date: Thu, 13 Jan 2005 10:29:44 -0800 From: Tim Bray Subject: PaceExtensibilityAndVersioningNoScenarios To: Atom Syntax Message-id: <18D1D0FE-6591-11D9-9616-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 -0 I could live with this, but PaceMusUnderstandElement achieves 80% of the benefit at 20% of the cost. -Tim From owner-atom-syntax@mail.imc.org Thu Jan 13 14:34: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 OAA06747 for ; Thu, 13 Jan 2005 14:34: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 j0DJLlce004028; Thu, 13 Jan 2005 11:21: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 j0DJLl0k004027; Thu, 13 Jan 2005 11:21:47 -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 j0DJLkOx004016 for ; Thu, 13 Jan 2005 11:21:46 -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 j0DJLkVu010594 for ; Thu, 13 Jan 2005 12:21:46 -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 <0IA900JUZSG9GX@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 13 Jan 2005 12:21:46 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA9000KJSFT7R@mail.sun.net> for atom-syntax@imc.org; Thu, 13 Jan 2005 12:21:45 -0700 (MST) Date: Thu, 13 Jan 2005 10:36:43 -0800 From: Tim Bray Subject: PaceMustUnderstandElement To: Atom Syntax Message-id: <1268D6AA-6592-11D9-9616-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 +1. The objections to this fall into two forms: 1. We don't have prior art in the syndication space that proves this is needed. 2. This is someone else's problem, e.g. SOAP I can see both those arguments, but when I re-visit and re-read this, the implementation is so falling-off-a-log obvious, like one small subroutine, that if you're doing cost/benefit math, the cost is very close to zero. And I can easily imagine lots of scenarios in which it would be extremely empowering for someone to design an extension and be confident that their feeds would be processed only by software that knows it. And a decision to leave this out feels like hubris to me. "We're so sure we got the core right that we can leave out an extremely cheap potentially-valuable extension point." I doubt it. -Tim From owner-atom-syntax@mail.imc.org Thu Jan 13 15:36: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 PAA12824 for ; Thu, 13 Jan 2005 15:36: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 j0DKIAXd065247; Thu, 13 Jan 2005 12: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 j0DKIAWX065231; Thu, 13 Jan 2005 12:18: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-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 j0DKI80v065164 for ; Thu, 13 Jan 2005 12:18:09 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.110] (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 j0DKI0Kj019929; Thu, 13 Jan 2005 15:18:01 -0500 (EST) Message-ID: <41E6D776.3060106@intertwingly.net> Date: Thu, 13 Jan 2005 15:17:58 -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: Danny Ayers CC: David Powell , atom-syntax@imc.org Subject: Re: Posted PaceExtensionConstruct References: <1113271276.20050112211950@djpowell.net> <244067D8-64FE-11D9-8584-000A95DC3D90@mac.com> <7010540965.20050113012812@djpowell.net> <4207AC7C-6503-11D9-8584-000A95DC3D90@mac.com> <949293416.20050113084507@djpowell.net> <1f2ed5cd05011303136730fced@mail.gmail.com> In-Reply-To: <1f2ed5cd05011303136730fced@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: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > On Thu, 13 Jan 2005 08:45:07 +0000, David Powell wrote: > > I very much like the general approach of this Pace, I reckon it's very > close to what's needed. > > If there is some way to lose atom:notation without introducing > ambiguity it would be better (if something is needed, what about > atom:type as used on content - might that be a suitable replacement?) How about: "a Structured Extension construct must have at least one required attribute or one required child element"? - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Jan 13 15:44: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 PAA13886 for ; Thu, 13 Jan 2005 15:44: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 j0DKNbGV069263; Thu, 13 Jan 2005 12:23: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 j0DKNbph069262; Thu, 13 Jan 2005 12:23:37 -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 j0DKNahk069197 for ; Thu, 13 Jan 2005 12:23:36 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.110] (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 j0DKNRkc011493 for ; Thu, 13 Jan 2005 15:23:28 -0500 (EST) Message-ID: <41E6D8BC.405@intertwingly.net> Date: Thu, 13 Jan 2005 15:23: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: atom-syntax@imc.org Subject: AtomPubIssuesList for 2005/01/11 - REVISED 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> In-Reply-To: <41E444EB.6030903@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 Based on input received, I've moved PacePropertyDesign to the Recommended for Closure category, and added PaceExtensionConstruct to the Currently Under Discussion category. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Jan 13 15:58: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 PAA15352 for ; Thu, 13 Jan 2005 15:58: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 j0DKa9pu084794; Thu, 13 Jan 2005 12: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 j0DKa9Tv084793; Thu, 13 Jan 2005 12:36: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 j0DKa856084770 for ; Thu, 13 Jan 2005 12:36: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); Fri, 14 Jan 2005 09:36:47 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 14 Jan 2005 07:36:06 +1100 Subject: Re: PaceMustUnderstandElement From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1268D6AA-6592-11D9-9616-000A95A51C9E@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 -1 I still have misgivings about the underlying model, mainly due to it's binary nature. What happens if at some future point we want to rev the definition of some element which has already been revved once before in it's history? It already has the mU wart, and thus version 3 of that element would be indistinguishable from version 2. Or do we introduce a mustUnderstandAgain attribute? e. From owner-atom-syntax@mail.imc.org Thu Jan 13 16:06: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 QAA16482 for ; Thu, 13 Jan 2005 16:06: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 j0DKqRUU004638; Thu, 13 Jan 2005 12:52: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 j0DKqRHD004637; Thu, 13 Jan 2005 12:52: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 j0DKqPpx004595 for ; Thu, 13 Jan 2005 12:52:26 -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 j0DKpNp3013621; Thu, 13 Jan 2005 20:51:29 GMT In-Reply-To: <1268D6AA-6592-11D9-9616-000A95A51C9E@sun.com> References: <1268D6AA-6592-11D9-9616-000A95A51C9E@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6-640748571; protocol="application/pkcs7-signature" Message-Id: Cc: Atom Syntax From: Graham Subject: Re: PaceMustUnderstandElement Date: Thu, 13 Jan 2005 20:51:23 +0000 To: Tim Bray X-Mailer: Apple Mail (2.619) 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-640748571 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 13 Jan 2005, at 6:36 pm, Tim Bray wrote: > The objections to this fall into two forms: > 1. We don't have prior art in the syndication space that proves this > is needed. > 2. This is someone else's problem, e.g. SOAP 3. We don't need it and it won't be implemented anywhere and it's extremely open to abuse and/or failure. We are not having a mustUnderstand mechanism. Graham --Apple-Mail-6-640748571 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 9w0BCQUxDxcNMDUwMTEzMjA1MTI0WjAjBgkqhkiG9w0BCQQxFgQUYnVfFVNGDCUJR6GvHM6gs5So TRIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAA3AjUrlAn4BtOw6tidO/tiTy J5kEHG86Z7zjEPO5vGFvIyvB1HL3geGAIwyXhbFliX63vRqz2Z9HFNmJD1TPacupjJS+zU0wtc0U uoIU8pw1jaEfbxW9+kG+BbCENAguWj+Iop6EDf5DzjIaDRe1wT3uqCpn4s7+eOmxX/LLRf4chcUe TMDTfJ8Y7SlDhrbxuBfKFO+r6i/M3EslqZfJWsnNZmCjb3Qoj/Mj9BY49GIAljuHrdrBrcOR4uB9 DYfhhsSLCkzFMMtmwORn9lMXBA3vSk72TkZIgyi7EiOebaVXt3kxMH+NphGT0rvvUO+0csh5VrwY My61237uuLM7EgAAAAAAAA== --Apple-Mail-6-640748571-- From owner-atom-syntax@mail.imc.org Thu Jan 13 17:07: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 RAA27874 for ; Thu, 13 Jan 2005 17:07: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 j0DLuM5q055290; Thu, 13 Jan 2005 13:56: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 j0DLuMtY055289; Thu, 13 Jan 2005 13:56:22 -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 j0DLuLnh055278 for ; Thu, 13 Jan 2005 13:56: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 (sccrmhc11) with SMTP id <20050113215616011000ht39e>; Thu, 13 Jan 2005 21:56:16 +0000 Date: Thu, 13 Jan 2005 14:56:15 -0700 Subject: Re: PaceMustUnderstandElement 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 Thursday, January 13, 2005, at 01:51 PM, Graham wrote: > On 13 Jan 2005, at 6:36 pm, Tim Bray wrote: >> The objections to this fall into two forms: >> 1. We don't have prior art in the syndication space that proves this >> is needed. >> 2. This is someone else's problem, e.g. SOAP > > 3. We don't need it That's #1 above > and it won't be implemented anywhere Given the utter simplicity of implementation, I think it will be implemented in many clients. If no publisher ever uses it, then that's very little loss. (However, I don't expect it to be implemented universally. How serious a problem will that be? ) If people make extensions and use Atom for uses that they wouldn't have lacking mU, then that could be a significant gain--we'll see. > and it's extremely open to abuse Could you explain? Do you mean that people who don't implement support for certain extensions will feel abused? If so, here's why I don't think makes the situation any worse--if anything it makes it better: If a significant number of feeds, or if significant feeds, use an extension that really IS important to understand in order to process the feed in a non-bad way, clients that don't support it will get complaints whether they ignore it (no ) or report that they can't process it (with ). If they report that they can't process it, the complaints will be along the lines of "I need to access this feed! Please add support (or I'll get a new feed reader)!" If they ignore it, the complaints will be "This feed doesn't show up properly! Fix it (or I'll get a new feed reader)!" and "Your feed reader is causing problems with my system because it's partially processing my feed, but it isn't doing XYZ with extension ABC! Fix it you lazy, stinking, system-wrecking hacker!" If the problem is a significant number of feeds, or significant feeds, marking something mU when it really doesn't hurt to not understand it, then yes, developers will get unnecessary complaints. That could lead to: A) More extensions being supported by more applications B) Applications with the user-option to ignore mU (hopefully on a feed-by-feed and/or extension-by-extension basis) C) Developers complaining to publishers D) Developers publicly criticizing publishers E) Developers telling their customers to complain to publishers F) A few customers actually doing so G) Some publishers getting their act together A little pain, sure. But how likely is it that the problems will outweigh the benefits? We don't have prior experience to gauge either by. I think the potential for pain is small enough to make the experiment worth the risk. > and it's extremely open to failure. Could you explain? From owner-atom-syntax@mail.imc.org Thu Jan 13 17:40: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 RAA00696 for ; Thu, 13 Jan 2005 17:40: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 j0DMVOZi060374; Thu, 13 Jan 2005 14:31: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 j0DMVOe8060373; Thu, 13 Jan 2005 14:31:24 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DMVNUX060353 for ; Thu, 13 Jan 2005 14:31:23 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta06-winn.mailhost.ntl.com ([212.250.162.8]) by mta05-winn.mailhost.ntl.com with ESMTP id <20050113223118.UZWD24912.mta05-winn.mailhost.ntl.com@aamta06-winn.mailhost.ntl.com>; Thu, 13 Jan 2005 22:31:18 +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 <20050113223117.CPWB7271.aamta06-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Thu, 13 Jan 2005 22:31:17 +0000 Date: Thu, 13 Jan 2005 22:31:15 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <1836569775.20050113223115@djpowell.net> To: Sam Ruby CC: Danny Ayers , atom-syntax@imc.org Subject: Re: Posted PaceExtensionConstruct In-Reply-To: <41E6D776.3060106@intertwingly.net> References: <1113271276.20050112211950@djpowell.net> <244067D8-64FE-11D9-8584-000A95DC3D90@mac.com> <7010540965.20050113012812@djpowell.net> <4207AC7C-6503-11D9-8584-000A95DC3D90@mac.com> <949293416.20050113084507@djpowell.net> <1f2ed5cd05011303136730fced@mail.gmail.com> <41E6D776.3060106@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 Thursday, January 13, 2005, 8:17:58 PM, you wrote: > Danny Ayers wrote: >> On Thu, 13 Jan 2005 08:45:07 +0000, David Powell wrote: >> >> I very much like the general approach of this Pace, I reckon it's very >> close to what's needed. >> >> If there is some way to lose atom:notation without introducing >> ambiguity it would be better (if something is needed, what about >> atom:type as used on content - might that be a suitable replacement?) > How about: "a Structured Extension construct must have at least one > required attribute or one required child element"? Yeah, that would work, but it would mean that a Structured Extension such as: some mixed content would need to force an unnecessary attribute in there. Probably not a big problem though. An advantage of explicit atom:notation attributes, is that we could make atom:notation values extensible in the same way as link rel values, so that other standard notations could be defined that were more expressive than Simple Extensions (with "structured" as the fallback interpretation for unknown notations). But I don't know whether that would be useful. I'm undecided. The requirement for explicit namespace qualification of the atom:notation attribute is ugly, this would be tidier. -- Dave From owner-atom-syntax@mail.imc.org Thu Jan 13 17:41: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 RAA00774 for ; Thu, 13 Jan 2005 17:41: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 j0DMU7s0060265; Thu, 13 Jan 2005 14:30: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 j0DMU7Zh060264; Thu, 13 Jan 2005 14:30:07 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DMU6EE060201 for ; Thu, 13 Jan 2005 14:30:06 -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 <20050113222950.VQZX4706.mta08-winn.mailhost.ntl.com@aamta06-winn.mailhost.ntl.com>; Thu, 13 Jan 2005 22:29:50 +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 <20050113222950.CKYN7271.aamta06-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Thu, 13 Jan 2005 22:29:50 +0000 Date: Thu, 13 Jan 2005 22:29:48 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <537002204.20050113222948@djpowell.net> To: Tim Bray CC: Atom Syntax Subject: Re: PaceMustUnderstandElement In-Reply-To: <1268D6AA-6592-11D9-9616-000A95A51C9E@sun.com> References: <1268D6AA-6592-11D9-9616-000A95A51C9E@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 Does anyone have any example use cases for mustUnderstand? -- Dave From owner-atom-syntax@mail.imc.org Thu Jan 13 17:45: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 RAA01023 for ; Thu, 13 Jan 2005 17:45: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 j0DMaxfY060720; Thu, 13 Jan 2005 14:36: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 j0DMaxjX060719; Thu, 13 Jan 2005 14:36:59 -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 j0DMawK8060701 for ; Thu, 13 Jan 2005 14:36:58 -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 j0DMYEie005142; Thu, 13 Jan 2005 22:34:19 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7-646920177; protocol="application/pkcs7-signature" Message-Id: <4150A704-65B3-11D9-8584-000A95DC3D90@mac.com> Cc: atom-syntax@imc.org From: Graham Subject: Re: PaceMustUnderstandElement Date: Thu, 13 Jan 2005 22:34:15 +0000 To: Antone Roundy X-Mailer: Apple Mail (2.619) 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-646920177 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 13 Jan 2005, at 9:56 pm, Antone Roundy wrote: >> 3. We don't need it > That's #1 above #1 is dependent on there not being prior art. Even if there were, we still wouldn't need it. >> and it won't be implemented anywhere > Given the utter simplicity of implementation, I think it will be > implemented in many clients. What's the value in implementing it? Yes its simple, but it means x% of feeds will now fail in my client, and I will get x% more complaints. What's the benefit to users? What I'll be doing in Shrook if we have this, is ignoring extensions I know of but don't implement (and know that not supporting them does damage), and in all other cases processing the document. >> and it's extremely open to abuse > Could you explain? I'm imagining someone thinking (or just deciding) they need to put all the extensions they use in mustUnderstand, whether they must be understood or not. If more than a couple of these feeds like this show up then clients will just give up paying any attention to mU. > If they report that they can't process it, the complaints will be > along the lines of "I need to access this feed! Please add support (or > I'll get a new feed reader)!" If they ignore it, the complaints will > be "This feed doesn't show up properly! Fix it (or I'll get a new feed > reader)!". Exactly, the feed not working properly will be obvious to the user whether it matters or not. >> and it's extremely open to failure. > Could you explain? Most obviously, typos, incorrect implementations, poor testing etc. All parts of atom are susceptible to this, of course, but mU just creates another potential point of failure, and with no hope of recovery, since the processor must discard the whole document. The main problem ince a possibly large percentage won't implement it, using mustUnderstand in a feed doesn't prevent whatever dire consequences there might be of ignoring the elements that must be understood, which makes the proposed system unable to serve its purpose. --Apple-Mail-7-646920177 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 9w0BCQUxDxcNMDUwMTEzMjIzNDE1WjAjBgkqhkiG9w0BCQQxFgQU8KZmt8bTU7+3ag+WwKZdaRj7 BXIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEABewclU0y9D//8cJoFjdFNO6q AcjIRB3MWHZh9eOQTJswEiPi3ljq4x+PX5pHl+3zcW86TV+LxjaF5lSohDP0qJMVSZ55j41kd3wh uY4OKtEwx2prIzRumbsLJcKWTx83AozXk8pdtv+g6Lhib4UxWKvbygGsowNUnDHjlXhO19olnJnA 3qNY2iKgc1yU2ZFYcDX01CbVKM+D/Y68aVo+RYFEBuAie5lVUKOp8AjqEzTKihGIv10eBeH0YfNT IYHaX8jb2bYCf3dg1tzZRiraIHCW6H27fNMjLg8z/IxfPu29BsStqHYXHj7ycrBjJO6bDOQacDeX lAoDqQMur8JwiQAAAAAAAA== --Apple-Mail-7-646920177-- From owner-atom-syntax@mail.imc.org Thu Jan 13 17:54: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 RAA01856 for ; Thu, 13 Jan 2005 17:54: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 j0DMk6wb061386; Thu, 13 Jan 2005 14:46: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 j0DMk6ab061385; Thu, 13 Jan 2005 14:46: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-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 j0DMk6tg061378 for ; Thu, 13 Jan 2005 14:46:06 -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 j0DMk1dt001355 for ; Thu, 13 Jan 2005 15:46:06 -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 <0IAA00HOJ1WOMO@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 13 Jan 2005 15:46:00 -0700 (MST) Received: from [192.168.1.40] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAA00K911WN5E@mail.sun.net> for atom-syntax@imc.org; Thu, 13 Jan 2005 15:46:00 -0700 (MST) Date: Thu, 13 Jan 2005 14:46:06 -0800 From: Tim Bray Subject: Re: PaceMustUnderstandElement In-reply-to: <537002204.20050113222948@djpowell.net> To: David Powell 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: <1268D6AA-6592-11D9-9616-000A95A51C9E@sun.com> <537002204.20050113222948@djpowell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 13, 2005, at 2:29 PM, David Powell wrote: > Does anyone have any example use cases for mustUnderstand? 1. A stream of financial disclosures from a public company in a highly-regulated industry. The legislation is very clear that they may not say anything in public unaccompanied by disclaimers and limitation-of-liability statements. The financial industry gets together an introduces an extension that requests clients to display these disclaimers in a fashion that meets the regulatory requirements. If Atom has MustUnderstand, compliant clients that can't do this will never fail to display the appropriate material, and this reduces the risk of litigation and makes it more likely that such feeds will be created. 2. A stream of information that uses a special-purpose digital-signature scheme to establish the authenticity of the information. People should not act on this information without checking the signature. A person using a conformant Atom client can be sure that they won't see anything that hasn't been checked. -Tim From owner-atom-syntax@mail.imc.org Thu Jan 13 18:07: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 SAA03137 for ; Thu, 13 Jan 2005 18:07: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 j0DMx6Vi063505; Thu, 13 Jan 2005 14:59: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 j0DMx6LS063504; Thu, 13 Jan 2005 14:59:06 -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] (adsl-66-125-125-68.dsl.pltn13.pacbell.net [66.125.125.68]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DMx2J1063490; Thu, 13 Jan 2005 14:59:02 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <540e37320501131429592e2a8a@mail.gmail.com> References: <540e37320501131429592e2a8a@mail.gmail.com> Date: Thu, 13 Jan 2005 14:59:01 -0800 To: "Roger B." From: Paul Hoffman / IMC Subject: Re: PaceMustUnderstandElement Cc: atom-syntax@imc.org 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 4:29 PM -0600 1/13/05, Roger B. wrote: >All it will take is an A-lister or three on a mission to essentially >force every general-use client developer to support whatever pet >extension they're fired up about that week, no matter how >ill-conceived. Are you saying that Atom 1.0 should not be extendable at all? That is, should we take out the namespace mechanism altogether? I don't remember hearing support for that before. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Jan 13 18:15: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 SAA04119 for ; Thu, 13 Jan 2005 18:15: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 j0DN4cGJ064175; Thu, 13 Jan 2005 15:04: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 j0DN4cL1064174; Thu, 13 Jan 2005 15:04: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 j0DN4bLi064158 for ; Thu, 13 Jan 2005 15:04:37 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.9]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CpE0W-0003Y0-UD; Thu, 13 Jan 2005 23:04:01 +0000 Message-ID: <41E6FE76.1050204@franklinmint.fm> Date: Thu, 13 Jan 2005 18:04:22 -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: Danny Ayers CC: atom-syntax@imc.org Subject: Re: Top 100s References: <1f2ed5cd0501131009ef1b954@mail.gmail.com> In-Reply-To: <1f2ed5cd0501131009ef1b954@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 Danny Ayers wrote: > fyi, Dare has blogged on "Syndicating Ordered Lists" pointing to > Netflix's rather thin RSS 2.0 feed, pointing to some holes in the > format(s). I know this scenario came up a while back somewhere around > 'order', I'm not really sure how well covered it is now (or needs to > be). OK, there are two issues there. 1 is ordering of the items, while the second is something similar to versioning. It occurs to me that Roy's PaceFeedRecursive might solve the second problem pretty simply. Netflix Top 100 foo Netflix Top 100 -- Week of 2005-01-07 bar ... 100 movies ... ... next week ... Netflix Top 100 foo Netflix Top 100 -- Week of 2005-01-14 baz ... 100 movies ... From owner-atom-syntax@mail.imc.org Thu Jan 13 18:27: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 RAA00698 for ; Thu, 13 Jan 2005 17:40: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 j0DMTlRv060173; Thu, 13 Jan 2005 14:29: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 j0DMTlIR060172; Thu, 13 Jan 2005 14:29:47 -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 j0DMTkSf060146 for ; Thu, 13 Jan 2005 14:29:46 -0800 (PST) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 71so140284wri for ; Thu, 13 Jan 2005 14:29: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=GB9jWwiaftT/Zv+9pCIU8JbuQN/tOYM4QE115LRwftnEV2/itjPAfU8OKL/MqUv+6qDiFNkcDAP50UC5ARXvyRs5n4Kq1Hy5PszbUSEFe+mWbNqYmnL7ByP268DaMmGKM0A2gAnLDYkMAw7jHpWLB+kOxWU24B23OF0MQmMbdss= Received: by 10.54.10.15 with SMTP id 15mr36974wrj; Thu, 13 Jan 2005 14:29:41 -0800 (PST) Received: by 10.54.18.2 with HTTP; Thu, 13 Jan 2005 14:29:40 -0800 (PST) Message-ID: <540e37320501131429592e2a8a@mail.gmail.com> Date: Thu, 13 Jan 2005 16:29:40 -0600 From: "Roger B." Reply-To: "Roger B." To: Antone Roundy Subject: Re: PaceMustUnderstandElement Cc: atom-syntax@imc.org 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 > But how likely is it that the problems will > outweigh the benefits? Antone: Extremely, in my opinion. A big -1 on this one. All it will take is an A-lister or three on a mission to essentially force every general-use client developer to support whatever pet extension they're fired up about that week, no matter how ill-conceived. And offering a user-controlled bypass isn't an option... I'm not ever gonna be in the mood to be sued by someone because my app allowed the user to turn off a feed's bundle of "must understand" DRM elements. If a publisher's data requires non-core elements to be minimally useful, then I'd say Atom is the wrong format for that data. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Thu Jan 13 18:38: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 SAA05970 for ; Thu, 13 Jan 2005 18:38: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 j0DNWhPI072975; Thu, 13 Jan 2005 15:32: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 j0DNWhBr072974; Thu, 13 Jan 2005 15:32:43 -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 j0DNWhNb072965 for ; Thu, 13 Jan 2005 15:32:43 -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 <20050113233237011000oe89e>; Thu, 13 Jan 2005 23:32:37 +0000 Date: Thu, 13 Jan 2005 16:32:36 -0700 Subject: Re: PaceMustUnderstandElement 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: <4150A704-65B3-11D9-8584-000A95DC3D90@mac.com> Message-Id: <686F9DC9-65BB-11D9-859E-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 13, 2005, at 03:34 PM, Graham wrote: > The main problem ince a possibly large percentage won't implement it, > using mustUnderstand in a feed doesn't prevent whatever dire > consequences there might be of ignoring the elements that must be > understood, which makes the proposed system unable to serve its > purpose. > Okay, mU offers no guaranteed protection against bad side effects, and the spec text should make this very clear. It would still be useful for USERS who want to ensure that their feed reader is processing feeds correctly, as in the examples Tim gave (sorry, no reference--it's not listed in the archive yet). From owner-atom-syntax@mail.imc.org Thu Jan 13 18: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 SAA06760 for ; Thu, 13 Jan 2005 18: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 j0DNgPmK074839; Thu, 13 Jan 2005 15: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 j0DNgPGv074838; Thu, 13 Jan 2005 15:42:25 -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 j0DNgOY7074813 for ; Thu, 13 Jan 2005 15:42: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 (sccrmhc12) with SMTP id <200501132342190120015tkte>; Thu, 13 Jan 2005 23:42:19 +0000 Date: Thu, 13 Jan 2005 16:42:18 -0700 Subject: Re: PaceMustUnderstandElement 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: <540e37320501131429592e2a8a@mail.gmail.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, January 13, 2005, at 03:29 PM, Roger B. wrote: >> But how likely is it that the problems will >> outweigh the benefits? > > Antone: Extremely, in my opinion. A big -1 on this one. > > All it will take is an A-lister or three on a mission to essentially > force every general-use client developer to support whatever pet > extension they're fired up about that week, no matter how > ill-conceived. ...or to turn an A-lister into a B-lister. Yeah, if this happens, it will cause some pain. But hey, maybe that's a good thing. After all, we in the syndication community have been historically proven to love sniping, arguing and fighting. > And offering a user-controlled bypass isn't an > option... I'm not ever gonna be in the mood to be sued by someone > because my app allowed the user to turn off a feed's bundle of "must > understand" DRM elements. Okay, so, as mentioned in my last email, mU is there to benefit the client, not to guarantee protection to the publisher. Maybe we should change it to "should-understand" or "important"..., "SHOULD NOT process the document...", etc. From owner-atom-syntax@mail.imc.org Thu Jan 13 18: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 SAA06858 for ; Thu, 13 Jan 2005 18:50: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 j0DNgCka074744; Thu, 13 Jan 2005 15: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 j0DNgCa5074742; Thu, 13 Jan 2005 15:42: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.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DNgBic074689 for ; Thu, 13 Jan 2005 15:42:11 -0800 (PST) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so233328wra for ; Thu, 13 Jan 2005 15:42:05 -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=IAfe99eRuK4JgSkQi8biRPmhcxTdgYAbAldz7+wU2Yc+CW58PYUz7/d3tw/pFfJFsc8tUL6eqWXsrF5eq79LOYt4vShbyF3+cHnQdY0Kk6tlm1Lbnc8/f6Ew8MdDJLGfzufVLnMPDtngVsbF41yMXLIfhRyQQB7WIK2+jLt1WJ8= Received: by 10.54.50.50 with SMTP id x50mr116134wrx; Thu, 13 Jan 2005 15:42:05 -0800 (PST) Received: by 10.54.18.2 with HTTP; Thu, 13 Jan 2005 15:42:05 -0800 (PST) Message-ID: <540e3732050113154215af7ae2@mail.gmail.com> Date: Thu, 13 Jan 2005 17:42:05 -0600 From: "Roger B." Reply-To: "Roger B." To: Paul Hoffman / IMC Subject: Re: PaceMustUnderstandElement Cc: atom-syntax@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <540e37320501131429592e2a8a@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Are you saying that Atom 1.0 should not be extendable at all? Paul: Not at all. I'm simply saying that "must understand" gives influential publishers the power to force the hands of developers, something that RSS (wisely) doesn't provide. In addition, I have a philosophical objection, which I touched on briefly in my last message. Atom feeds should contain well-formed entries... if an entry requires non-core elements to make it minimally useful, I'd argue it isn't well-formed, and the use of Atom was ill-advised. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Thu Jan 13 18:52: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 SAA06987 for ; Thu, 13 Jan 2005 18:52: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 j0DNlSKS075388; Thu, 13 Jan 2005 15:47: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 j0DNlS8M075387; Thu, 13 Jan 2005 15:47:28 -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 j0DNlRYS075379 for ; Thu, 13 Jan 2005 15:47:28 -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 j0DNkUNt019807; Thu, 13 Jan 2005 23:46:30 GMT In-Reply-To: References: <1268D6AA-6592-11D9-9616-000A95A51C9E@sun.com> <537002204.20050113222948@djpowell.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8-651257852; protocol="application/pkcs7-signature" Message-Id: <5AC55B18-65BD-11D9-8584-000A95DC3D90@mac.com> Cc: Atom Syntax , David Powell From: Graham Subject: Re: PaceMustUnderstandElement Date: Thu, 13 Jan 2005 23:46:32 +0000 To: Tim Bray X-Mailer: Apple Mail (2.619) 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-651257852 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 13 Jan 2005, at 10:46 pm, Tim Bray wrote: > 1. A stream of financial disclosures from a public company in a > highly-regulated industry. The legislation is very clear that they > may not say anything in public unaccompanied by disclaimers and > limitation-of-liability statements. The financial industry gets > together an introduces an extension that requests clients to display > these disclaimers in a fashion that meets the regulatory requirements. > If Atom has MustUnderstand, compliant clients that can't do this will > never fail to display the appropriate material, and this reduces the > risk of litigation and makes it more likely that such feeds will be > created. I can't imagine these people would use mustUnderstand to do that. If it's important, they'll want to put it in content too. > 2. A stream of information that uses a special-purpose > digital-signature scheme to establish the authenticity of the > information. People should not act on this information without > checking the signature. A person using a conformant Atom client can > be sure that they won't see anything that hasn't been checked. Um, couldn't the malicious person easily remove the mustUnderstand element while they're adding spoofed information? Can you try a bit harder with number 3? Graham --Apple-Mail-8-651257852 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 9w0BCQUxDxcNMDUwMTEzMjM0NjMzWjAjBgkqhkiG9w0BCQQxFgQUQ7HK8rI+U8DOA6eJh/VPdq/0 emgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAn9bqkOrMW7gE68fVg9jLdmNG GjWv+P5CKsimQMv+gXXiBuD9Mz/JU31h47zMISuXpg/VRpbvL+OQ/QmMGSgu0JDL3+K434pf32d+ jKUiEQISp+ijtbNPMfXYaE4xcHD4H4OLWCnPGbanRhRcQJNBSSXmxHpo86bA8GBTi4ZAUQB9fwox tGVkV4YxLiLL9WZdEk7yElbwocSVcKz9eyhmcihRrDYbG2r4+7rPF4SJKY6a3qS5G77RDHiorn5S TL+ZdNpT+z9D6+vVJUM9r3shWMJSoQkwrvwjS3I/iiFoiAImWrIcg7wpD/WcJmFaoBE+ASz22p/t lhuSnjwzhx0aHgAAAAAAAA== --Apple-Mail-8-651257852-- From owner-atom-syntax@mail.imc.org Thu Jan 13 18:55: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 SAA07341 for ; Thu, 13 Jan 2005 18:55: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 j0DNok8l075616; Thu, 13 Jan 2005 15: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 j0DNokhL075615; Thu, 13 Jan 2005 15:50: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 j0DNoj0R075606 for ; Thu, 13 Jan 2005 15:50: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 <20050113235039012000uoahe>; Thu, 13 Jan 2005 23:50:40 +0000 Date: Thu, 13 Jan 2005 16:50:39 -0700 Subject: Re: Posted PaceExtensionConstruct 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: <1836569775.20050113223115@djpowell.net> 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, January 13, 2005, at 03:31 PM, David Powell wrote: >>> If there is some way to lose atom:notation without introducing >>> ambiguity it would be better (if something is needed, what about >>> atom:type as used on content - might that be a suitable replacement?) > >> How about: "a Structured Extension construct must have at least one >> required attribute or one required child element"? > > Yeah, that would work, but it would mean that a Structured Extension > such as: > > some mixed content > > would need to force an unnecessary attribute in there. Probably not a > big problem though. > Forcing 'atom:notation="structured"' into all structured extensions, whether they have other required attributes or not would have even more impact. Just a note: the above example would need to be something like the following to set a default namespace: some mixed content ...not that it wouldn't be easy to construct an example that didn't, a la: some mixed content From owner-atom-syntax@mail.imc.org Thu Jan 13 19:01: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 TAA07850 for ; Thu, 13 Jan 2005 19: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 j0DNu4a5076155; Thu, 13 Jan 2005 15:56: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 j0DNu4Lp076154; Thu, 13 Jan 2005 15:56: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-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 j0DNu3op076141 for ; Thu, 13 Jan 2005 15:56:03 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.117] (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 j0DNtsKj007538; Thu, 13 Jan 2005 18:55:55 -0500 (EST) Message-ID: <41E70A89.3070203@intertwingly.net> Date: Thu, 13 Jan 2005 18: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 To: "Roy T. Fielding" CC: Atom WG Subject: Re: PaceFeedRecursive References: <9C395894-629F-11D9-B5EE-000D93324AD6@gbiv.com> In-Reply-To: <9C395894-629F-11D9-B5EE-000D93324AD6@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: > > I just created a starting point for a proposal on making the > feed element recursive, eliminating the need for RDF syntax, > atom:head, and a bunch of things proposed in other paces regarding > aggregators and digital signatures. > > http://www.intertwingly.net/wiki/pie/PaceFeedRecursive > > Unfortunately, I have a paper deadline on Tuesday and can't > procrastinate any longer, so someone else can finish the details > or I'll finish it later in the week. I realize that the proposal isn't flushed out, but a question nevertheless. The proposal apparently is for feeds to contain other feeds by containment. My question is whether it would make sense to also support feeds containing other feeds by reference, perhaps via a link element or via a src= attribute (analogous to content/@src defined in 5.12.2). A use case can be found here: http://www.decafbad.com/blog/2005/01/13/feed_playlists_versus_feed_urls The only additional requirement I can see is that it might make sense to have a separate mime type for feeds which only reference other feeds, and feeds which contain content. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Jan 13 19:04: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 TAA08116 for ; Thu, 13 Jan 2005 19:04: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 j0DNsEek075972; Thu, 13 Jan 2005 15:54: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 j0DNsEKW075971; Thu, 13 Jan 2005 15:54: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 j0DNsDEx075965 for ; Thu, 13 Jan 2005 15:54:13 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.9]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CpEmX-0004QB-LQ; Thu, 13 Jan 2005 23:53:37 +0000 Message-ID: <41E70A17.2040209@franklinmint.fm> Date: Thu, 13 Jan 2005 18:53: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: Tim Bray CC: David Powell , Atom Syntax Subject: Re: PaceMustUnderstandElement References: <1268D6AA-6592-11D9-9616-000A95A51C9E@sun.com> <537002204.20050113222948@djpowell.net> 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 Jan 13, 2005, at 2:29 PM, David Powell wrote: > >> Does anyone have any example use cases for mustUnderstand? > > > 1. A stream of financial disclosures from a public company in a > highly-regulated industry. The legislation is very clear that they may > not say anything in public unaccompanied by disclaimers and > limitation-of-liability statements. The financial industry gets > together an introduces an extension that requests clients to display > these disclaimers in a fashion that meets the regulatory requirements. > If Atom has MustUnderstand, compliant clients that can't do this will > never fail to display the appropriate material, and this reduces the > risk of litigation and makes it more likely that such feeds will be > created. > So they write a spec that "requires display", and now any client that doesn't "display" stuff can't use it? This proposal seems uniquely prone to abuse by "morons" and "assholes."[0] Why does the proposal equate "vocabularies" with XML Namespaces? I don't think the namespace spec does that(??). Is it possible to "understand a namespace"? Also, this proposal does seem to have real implementation costs for programs that don't use streaming parsers directly. For example, SafariRSS parses feeds with an XQuery script. They also store entries forever, but maybe they don't version feed properties. What happens to their implementation if a feed intermittently contains these mU declarations? I'm confused by it. Robert Sayre [0] http://diveintomark.org/archives/2004/08/16/specs http://www.google.com/search?q=morons+and+assholes From owner-atom-syntax@mail.imc.org Thu Jan 13 19:21: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 TAA09247 for ; Thu, 13 Jan 2005 19:21: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 j0E0G1Bm078216; Thu, 13 Jan 2005 16:16: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 j0E0G1dw078215; Thu, 13 Jan 2005 16: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 j0E0G0eS078209 for ; Thu, 13 Jan 2005 16:16:00 -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 j0E0G0Vu012936 for ; Thu, 13 Jan 2005 17:16:00 -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 <0IAA00J3162N0W@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 13 Jan 2005 17:16:00 -0700 (MST) Received: from [192.168.1.40] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAA0051S62MUN@mail.sun.net> for atom-syntax@imc.org; Thu, 13 Jan 2005 17:15:59 -0700 (MST) Date: Thu, 13 Jan 2005 16:16:07 -0800 From: Tim Bray Subject: Re: PaceMustUnderstandElement In-reply-to: <1268D6AA-6592-11D9-9616-000A95A51C9E@sun.com> To: Tim Bray Cc: Atom Syntax Message-id: <7C710278-65C1-11D9-9616-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: <1268D6AA-6592-11D9-9616-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 13, 2005, at 10:36 AM, Tim Bray wrote: > +1. The other Tim Bray, speaking as co-chair, observes that PaceMustUnderstandElement is hopelessly dead, with apparently no support and lots of detractors. Thank you. You may now return to your regularly scheduled programming. -Tim From owner-atom-syntax@mail.imc.org Thu Jan 13 19: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 TAA09248 for ; Thu, 13 Jan 2005 19:21: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 j0E0BMhB077592; Thu, 13 Jan 2005 16:11: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 j0E0BMJ9077591; Thu, 13 Jan 2005 16:11:22 -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 j0E0BLa0077573 for ; Thu, 13 Jan 2005 16:11:21 -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 9E161119 for ; Thu, 13 Jan 2005 16:11:14 -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 j0E0B9KB025479 for ; Thu, 13 Jan 2005 16:11:14 -0800 (PST) Date: Thu, 13 Jan 2005 16:27:27 -0800 From: Walter Underwood To: Atom Syntax Subject: Re: PaceMustUnderstandElement Message-ID: <6739A3346EF6B31509D7EB3B@diva.verity.com> In-Reply-To: References: <1268D6AA-6592-11D9-9616-000A95A51C9E@sun.com> <537002204.20050113222948@djpowell.net> 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 Excellent examples. Each of these could be handled without mustUnderstand. Define an extension for entries. Put the restricted content inside the extension. The extension would include the display constraints between the content portions and the disclaimer or authentication portions. This could mean duplicating some content elements inside the extension. On the other hand, it would add support for restricted content instead of redefining regular content as potentially restricted. wunder --On Thursday, January 13, 2005 02:46:06 PM -0800 Tim Bray wrote: > > On Jan 13, 2005, at 2:29 PM, David Powell wrote: > >> Does anyone have any example use cases for mustUnderstand? > > 1. A stream of financial disclosures from a public company in a highly-regulated industry. The legislation is very clear that they may not say anything in public unaccompanied by disclaimers and limitation-of-liability statements. The financial industry gets together an introduces an extension that requests clients to display these disclaimers in a fashion that meets the regulatory requirements. If Atom has MustUnderstand, compliant clients that can't do this will never fail to display the appropriate material, and this reduces the risk of litigation and makes it more likely that such feeds will be created. > > 2. A stream of information that uses a special-purpose digital-signature scheme to establish the authenticity of the information. People should not act on this information without checking the signature. A person using a conformant Atom client can be sure that they won't see anything that hasn't been checked. > > -Tim > -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Thu Jan 13 19:41: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 TAA10496 for ; Thu, 13 Jan 2005 19:41: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 j0E0ZAGE099664; Thu, 13 Jan 2005 16:35: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 j0E0ZAS1099663; Thu, 13 Jan 2005 16:35:10 -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 j0E0Z9qV099550 for ; Thu, 13 Jan 2005 16:35:09 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id g11so160232rne for ; Thu, 13 Jan 2005 16:35: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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=h5leIgKmx3iuNWXbIxDQrc9D6q9T+0ZwFsieTc402Bclpugb3zCrNNPJsqiPByQ92bK6hmX2uuBnhsyLXzmPei1j4MEcjEFN186zBG1Y5fFotCV8ZRuWYUr89bhvizSTKu4AdrN6nj23Ej4j6VasM+MdHG+YRoyuczYbrCiX1fY= Received: by 10.38.152.55 with SMTP id z55mr256341rnd; Thu, 13 Jan 2005 16:35:07 -0800 (PST) Received: by 10.38.151.21 with HTTP; Thu, 13 Jan 2005 16:35:06 -0800 (PST) Message-ID: <3f1451f50501131635431b7110@mail.gmail.com> Date: Thu, 13 Jan 2005 19:35:06 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Tim Bray Subject: Re: PaceMustUnderstandElement Cc: Atom Syntax In-Reply-To: <7C710278-65C1-11D9-9616-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1268D6AA-6592-11D9-9616-000A95A51C9E@sun.com> <7C710278-65C1-11D9-9616-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 13 Jan 2005 16:16:07 -0800, Tim Bray wrote: > > On Jan 13, 2005, at 10:36 AM, Tim Bray wrote: > > > +1. > > The other Tim Bray, speaking as co-chair, observes that > PaceMustUnderstandElement is hopelessly dead, with apparently no > support and lots of detractors. Thank you. You may now return to your > regularly scheduled programming. -Tim Yay! I'm glad this goes down with more than me as the lone detractor. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Thu Jan 13 19:50: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 TAA10823 for ; Thu, 13 Jan 2005 19:50: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 j0E0fuxh009011; Thu, 13 Jan 2005 16:41: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 j0E0fuqP009010; Thu, 13 Jan 2005 16:41:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from queue02-winn.mailhost.ntl.com (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0E0ftdV008805 for ; Thu, 13 Jan 2005 16:41:56 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta05-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050113203356.REKN22154.mta09-winn.mailhost.ntl.com@aamta05-winn.mailhost.ntl.com> for ; Thu, 13 Jan 2005 20:33:56 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta05-winn.mailhost.ntl.com with ESMTP id <20050113203356.VCIE769.aamta05-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com> for ; Thu, 13 Jan 2005 20:33:56 +0000 Date: Thu, 13 Jan 2005 20:33:53 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <42179080.20050113203353@djpowell.net> To: atom-syntax@imc.org Subject: Close PaceUriReferences 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 think that PaceUriReferences can be closed. It seems to have been incorporated into the -04 draft as part of the "Update URI terms for 2396bis" revision. http://www.intertwingly.net/wiki/pie/PaceUriReferences -- Dave From owner-atom-syntax@mail.imc.org Thu Jan 13 19:54: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 TAA11108 for ; Thu, 13 Jan 2005 19:54: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 j0E0jFln013475; Thu, 13 Jan 2005 16:45: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 j0E0jFdF013474; Thu, 13 Jan 2005 16:45:15 -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 j0E0jE34013108 for ; Thu, 13 Jan 2005 16:45:14 -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 j0E0iua09956; Fri, 14 Jan 2005 01:44:56 +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 2005011401445423:3470 ; Fri, 14 Jan 2005 01:44:54 +0100 In-Reply-To: <41E70A89.3070203@intertwingly.net> References: <9C395894-629F-11D9-B5EE-000D93324AD6@gbiv.com> <41E70A89.3070203@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <80A67B0B-65C5-11D9-BBF5-000D93324AD6@gbiv.com> Cc: Atom WG From: "Roy T. Fielding" Subject: Re: PaceFeedRecursive Date: Thu, 13 Jan 2005 16:44:52 -0800 To: Sam Ruby X-Mailer: Apple Mail (2.619) X-MIMETrack: Itemize by SMTP Server on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 01/14/2005 01:44:54 AM, Serialize by Router on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 01/14/2005 01:44:57 AM, Serialize complete at 01/14/2005 01:44:57 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: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 13, 2005, at 3:55 PM, Sam Ruby wrote: > I realize that the proposal isn't flushed out, but a question > nevertheless. > > The proposal apparently is for feeds to contain other feeds by > containment. My question is whether it would make sense to also > support feeds containing other feeds by reference, perhaps via a link > element or via a src= attribute (analogous to content/@src defined in > 5.12.2). Yes, I was thinking the same would apply to entry, would it not? > A use case can be found here: > > http://www.decafbad.com/blog/2005/01/13/feed_playlists_versus_feed_urls Also, the Nature feed of feeds that has been referenced a couple times. > The only additional requirement I can see is that it might make sense > to have a separate mime type for feeds which only reference other > feeds, and feeds which contain content. Hmm, my employer is fond of saying "everything is content" -- feeds are just another name for collections, and most systems agree that collections create an association between members which is content in itself. ....Roy From owner-atom-syntax@mail.imc.org Thu Jan 13 20:53: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 UAA15487 for ; Thu, 13 Jan 2005 20:53: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 j0E1gSks062833; Thu, 13 Jan 2005 17:42: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 j0E1gSZx062832; Thu, 13 Jan 2005 17:42:28 -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 j0E1gRpm062816 for ; Thu, 13 Jan 2005 17:42: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 93093124 for ; Thu, 13 Jan 2005 17:42:22 -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 j0E1gMKB025832 for ; Thu, 13 Jan 2005 17:42:22 -0800 (PST) Date: Thu, 13 Jan 2005 17:58:40 -0800 From: Walter Underwood To: Atom WG Subject: Re: PaceFeedRecursive Message-ID: In-Reply-To: <41E70A89.3070203@intertwingly.net> References: <9C395894-629F-11D9-B5EE-000D93324AD6@gbiv.com> <41E70A89.3070203@intertwingly.net> 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 Thursday, January 13, 2005 06:55:53 PM -0500 Sam Ruby wrote: > > The proposal apparently is for feeds to contain other feeds by containment. > My question is whether it would make sense to also support feeds containing > other feeds by reference, perhaps via a link element or via a src= attribute > (analogous to content/@src defined in 5.12.2). As someone maintaining a spider and search engine, I'm -1 on inclusion by reference. The additional complexity is just not worth it. If a referenced doc is a 404, is the feed state OK? Should I index it or not? Do I always need to re-visit referred docs when I revisit the main one? What do I do with loops? Do I index all the content as belonging to the main doc? What if that is included in something else by reference, can it still be a standalone item? For the same reasons, I'm not very hot on any sort of content by reference. But recursive feeds by reference opens up lots more issues. Basically, if you want your content in a search engine, it had better be accessible with a single GET. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Fri Jan 14 07:35: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 HAA03367 for ; Fri, 14 Jan 2005 07:35: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 j0ECR98u072542; Fri, 14 Jan 2005 04:27: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 j0ECR9DM072540; Fri, 14 Jan 2005 04:27:09 -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 j0ECR8hE072499 for ; Fri, 14 Jan 2005 04:27:09 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 47454 messnum 367160 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 14 Jan 2005 12:27:02 -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 47454) with SMTP; 14 Jan 2005 12:27:02 -0000 Message-ID: <41E7BA95.20201@dehora.net> Date: Fri, 14 Jan 2005 12:27:01 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: PaceMustUnderstandElement References: <1268D6AA-6592-11D9-9616-000A95A51C9E@sun.com> <41E7B932.10804@dehora.net> In-Reply-To: <41E7B932.10804@dehora.net> 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 Sorry Tim, one more concern and I'm done. I think mU introduces scenarios where content cannot be safely or properly processed without looking to the metadata for control codes, ie metadata no longer is advisory or supplementary information. I suspect this is a significant innovation in feed formats. cheers Bill Bill de hÓra wrote: > Tim Bray wrote: > >> >> +1. >> >> The objections to this fall into two forms: >> 1. We don't have prior art in the syndication space that proves this >> is needed. >> 2. This is someone else's problem, e.g. SOAP >> >> I can see both those arguments, but when I re-visit and re-read this, >> the implementation is so falling-off-a-log obvious, like one small >> subroutine, that if you're doing cost/benefit math, the cost is very >> close to zero. > > > > Hi Tim, > > I haven't decided yet. I would dearly like a sane way to inform the > downstream to Look Here. But I'm concerned; my expectation based on > experience with this sort of thing is that many people will think their > element must be understood and will not always consider that the other > data can be understood or useful without their specific extension - this > is a bit like the unwillingness to prioritize requirements in a software > project ("we have to have it all"). > > And it does seem to me to introduce barriers to content and/or > incidental complexity - I can't easily buy into the zero cost argument > when I consider the content. I believe mU might result in inaccessible > feeds and/or format extension wars fought by proxy. I don't even want > to think about what nastiness could happen in DRM, copyright or inline > advertising scenarios. For example, I think mU could be used to > introduce machine processable rights declarations by stealth, something > we have already agreed to stay away from for now. > > I guess my main concern is that mU is not so much a technical mechanism > for managing change, but a policy mechanism for controlling access. > > cheers > Bill > > From owner-atom-syntax@mail.imc.org Fri Jan 14 07:39: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 HAA03393 for ; Fri, 14 Jan 2005 07:39: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 j0ECLKJM070532; Fri, 14 Jan 2005 04:21: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 j0ECLKLh070531; Fri, 14 Jan 2005 04:21:20 -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 j0ECLJ1X070475 for ; Fri, 14 Jan 2005 04:21:20 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 83935 messnum 2835506 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 14 Jan 2005 12:21:11 -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 83935) with SMTP; 14 Jan 2005 12:21:11 -0000 Message-ID: <41E7B932.10804@dehora.net> Date: Fri, 14 Jan 2005 12:21:06 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: PaceMustUnderstandElement References: <1268D6AA-6592-11D9-9616-000A95A51C9E@sun.com> In-Reply-To: <1268D6AA-6592-11D9-9616-000A95A51C9E@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: > > +1. > > The objections to this fall into two forms: > 1. We don't have prior art in the syndication space that proves this is > needed. > 2. This is someone else's problem, e.g. SOAP > > I can see both those arguments, but when I re-visit and re-read this, > the implementation is so falling-off-a-log obvious, like one small > subroutine, that if you're doing cost/benefit math, the cost is very > close to zero. Hi Tim, I haven't decided yet. I would dearly like a sane way to inform the downstream to Look Here. But I'm concerned; my expectation based on experience with this sort of thing is that many people will think their element must be understood and will not always consider that the other data can be understood or useful without their specific extension - this is a bit like the unwillingness to prioritize requirements in a software project ("we have to have it all"). And it does seem to me to introduce barriers to content and/or incidental complexity - I can't easily buy into the zero cost argument when I consider the content. I believe mU might result in inaccessible feeds and/or format extension wars fought by proxy. I don't even want to think about what nastiness could happen in DRM, copyright or inline advertising scenarios. For example, I think mU could be used to introduce machine processable rights declarations by stealth, something we have already agreed to stay away from for now. I guess my main concern is that mU is not so much a technical mechanism for managing change, but a policy mechanism for controlling access. cheers Bill From owner-atom-syntax@mail.imc.org Fri Jan 14 09:49: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 JAA18133 for ; Fri, 14 Jan 2005 09:49: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 j0EEUper005162; Fri, 14 Jan 2005 06:30: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 j0EEUpFu005161; Fri, 14 Jan 2005 06:30:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail10.svc.cra.dublin.eircom.net (mail10.svc.cra.dublin.eircom.net [159.134.118.26]) by above.proper.com (8.12.11/8.12.9) with SMTP id j0EEUoNg005141 for ; Fri, 14 Jan 2005 06:30:51 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 77299 messnum 1949406 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 14 Jan 2005 14:30:45 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail10.svc.cra.dublin.eircom.net (qp 77299) with SMTP; 14 Jan 2005 14:30:45 -0000 Message-ID: <41E7D793.1040200@dehora.net> Date: Fri, 14 Jan 2005 14:30:43 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: PaceMustUnderstandElement References: <1268D6AA-6592-11D9-9616-000A95A51C9E@sun.com> <7C710278-65C1-11D9-9616-000A95A51C9E@sun.com> In-Reply-To: <7C710278-65C1-11D9-9616-000A95A51C9E@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 Jan 13, 2005, at 10:36 AM, Tim Bray wrote: > >> +1. > > > The other Tim Bray, speaking as co-chair, observes that > PaceMustUnderstandElement is hopelessly dead, with apparently no support > and lots of detractors. Thank you. You may now return to your > regularly scheduled programming. -Tim My comments went out before this hit my inbox, apologies. cheers Bill From owner-atom-syntax@mail.imc.org Fri Jan 14 13: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 NAA02887 for ; Fri, 14 Jan 2005 13:22: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 j0EIA85o046156; Fri, 14 Jan 2005 10: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 j0EIA84E046155; Fri, 14 Jan 2005 10:10: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 j0EIA6Q4046089 for ; Fri, 14 Jan 2005 10:10:08 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12ld24r.cable.mindspring.com ([69.86.136.155] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CpVsz-0004Cc-9f; Fri, 14 Jan 2005 18:09:25 +0000 Message-ID: <41E80AF4.1020405@franklinmint.fm> Date: Fri, 14 Jan 2005 13:09:56 -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: PaceExtensibilityAndVersioning 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: > > -0 > > I could live with this, but I think PaceMustUnderstandElement buys 80% > of the benefit with 20% of the cost/apparatus. -Tim > -1. I suspect everyone else giving PaceMustUnderstand -1s will feel the same. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Jan 14 13:23: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 NAA02947 for ; Fri, 14 Jan 2005 13:23: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 j0EIBuDc046421; Fri, 14 Jan 2005 10:11: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 j0EIBuh0046420; Fri, 14 Jan 2005 10:11: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 j0EIBuX9046414 for ; Fri, 14 Jan 2005 10:11:56 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12ld24r.cable.mindspring.com ([69.86.136.155] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CpVup-0004EG-SK; Fri, 14 Jan 2005 18:11:19 +0000 Message-ID: <41E80B6A.60007@franklinmint.fm> Date: Fri, 14 Jan 2005 13:11:54 -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: PaceMinimalEntryVersioning References: <8BC6F4B0-6591-11D9-9616-000A95A51C9E@sun.com> In-Reply-To: <8BC6F4B0-6591-11D9-9616-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: > > -1 > > I think this issue has been discussed to death and the current > consensus around atom:id and atom:updated will meet users' needs > simply and elegantly. Trying to achieve consensus on a generalized > abstract model of versioning is doomed to failure. -Tim > -1 as well. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Jan 14 13:23: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 NAA03000 for ; Fri, 14 Jan 2005 13: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 j0EIGDgo046853; Fri, 14 Jan 2005 10:16: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 j0EIGDj7046852; Fri, 14 Jan 2005 10:16: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 j0EIGCe4046845 for ; Fri, 14 Jan 2005 10:16:12 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12ld24r.cable.mindspring.com ([69.86.136.155] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CpVyx-0004GH-U4; Fri, 14 Jan 2005 18:15:36 +0000 Message-ID: <41E80C6A.5050509@franklinmint.fm> Date: Fri, 14 Jan 2005 13:16:10 -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: PaceSupersede References: <5ED81998-6593-11D9-9616-000A95A51C9E@sun.com> In-Reply-To: <5ED81998-6593-11D9-9616-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: > > -1 > > There are as many notions of versioning in the world as there are > applications in the world, and "supersedes" model, while not that > untypical, is far from universal. It doesn't deserve to get special > treatment in Atom core. -Tim -1 as well. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Jan 14 13: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 NAA03179 for ; Fri, 14 Jan 2005 13:27: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 j0EIB91w046328; Fri, 14 Jan 2005 10: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 j0EIB9qE046327; Fri, 14 Jan 2005 10:11: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 j0EIB8RY046321 for ; Fri, 14 Jan 2005 10:11:08 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12ld24r.cable.mindspring.com ([69.86.136.155] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CpVu3-0004DW-Uw; Fri, 14 Jan 2005 18:10:32 +0000 Message-ID: <41E80B3A.6020106@franklinmint.fm> Date: Fri, 14 Jan 2005 13:11:06 -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: PaceExtensionNamespace References: <4AF451E8-6591-11D9-9616-000A95A51C9E@sun.com> In-Reply-To: <4AF451E8-6591-11D9-9616-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: > > -1 > > Way too complex, feels like a negative return on the > complexity/benefit trade-off. -Tim > -1 for the same reasons. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Jan 14 13:35: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 NAA03482 for ; Fri, 14 Jan 2005 13:35: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 j0EIJAW8047189; Fri, 14 Jan 2005 10:19: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 j0EIJABD047188; Fri, 14 Jan 2005 10:19: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 j0EIJAVu047177 for ; Fri, 14 Jan 2005 10:19:10 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12ld24r.cable.mindspring.com ([69.86.136.155] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CpW1p-0004K0-DA; Fri, 14 Jan 2005 18:18:33 +0000 Message-ID: <41E80D1B.60504@franklinmint.fm> Date: Fri, 14 Jan 2005 13:19:07 -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: PacePropertyDesign References: <2AB3BED2-6593-11D9-9616-000A95A51C9E@sun.com> In-Reply-To: <2AB3BED2-6593-11D9-9616-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: > > This one shouldn't, in my opinion, be on our active-discussion queue, > because it's uncooked. That is to say, it doesn't actually propose > specific changes to our format or protocol drafts. > > Having said that, the thinking seems usefully clean and minimal, and I > wouldn't be surprised if a real Pace, including proposed draft > revisions, could be built out of this that would have a chance at > consensus. > > But having said that, the language is crucial. For example, I would > be -1 on any change that requires Atom implementors to have to > internalize the notions of "RDF XML Literal" or, really, having to > understand http://www.w3.org/1999/02/22-rdf-syntax-ns, which is > referenced by the Pace. > > Also, it seems like there's a missing piece. I'm pretty sure that if > we did it this way, it would be pretty easy to do a canonical and > simple mapping from Atom to RDF/XML (right?), and if so, someone > should write an I-D to define this, and I'd be in favor of adopting it > as a WG draft. -Tim Anybody up for writing this? I wrote the Pace, but I don't have time to write anything more on it, and I'm not an RDF expert anyway. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Jan 14 15:50: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 PAA15726 for ; Fri, 14 Jan 2005 15: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 j0EKbqmf038916; Fri, 14 Jan 2005 12: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 j0EKbqJO038913; Fri, 14 Jan 2005 12:37:52 -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 j0EKbpZ9038889 for ; Fri, 14 Jan 2005 12:37:51 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 1so1133738rny for ; Fri, 14 Jan 2005 12:37: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:mime-version:content-type:content-transfer-encoding; b=njScOd+SWukUyrDxzvsg10VYpKNkN6FX8WAe7Y5jq9jf3ArLEWpqaxdmeJrk8odcY9BJRS9tM7L/trdP31LcHvdT59YruepyHi84djxdIPO7f7qz2wAGKNm7yg3Om26RqQWSYyF9X3jpXOdrPEGPOrMOlmWBF7ymgsLarPitpaw= Received: by 10.38.179.48 with SMTP id b48mr164168rnf; Fri, 14 Jan 2005 12:37:46 -0800 (PST) Received: by 10.38.179.71 with HTTP; Fri, 14 Jan 2005 12:37:46 -0800 (PST) Message-ID: <1f2ed5cd0501141237701637f9@mail.gmail.com> Date: Fri, 14 Jan 2005 21:37:46 +0100 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: Feed, know thyself? 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 was just in the middle of putting the world to rights regarding feed discovery/subscription from browsers [1] when something occurred to me. Correct me if I'm wrong, but isn't one of the solutions for this to serve the feed with the Atom mime type, which will trigger an appropriate handler in the browser? If I remember correctly from previous discussions, there is a little snag with most browsers only passing the data, not the source URI. Thing is, with the spec as it currently stands, we don't have a link from the feed that can be guarenteed to point to the feed URI itself. Having the handler go back to a HTML page to do autodiscovery seems a little roundabout. Relevant spec bit pasted below. Thoughts? Cheers, Danny. 4.2.2 "atom:link" Element The "atom:link" element is a Link construct that conveys a URI associated with the feed. The nature of the relationship is determined by the construct's rel attribute. atom:head elements MUST contain at least one atom:link element with a rel attribute value of "alternate". atom:head elements MUST NOT contain more than one atom:link element with a rel attribute value of "alternate" that has the same type attribute value. [1] http://danja.typepad.com/uncooked/2005/01/life_the_univer.html -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Jan 14 15:58: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 PAA16733 for ; Fri, 14 Jan 2005 15:58: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 j0EKrIMv048703; Fri, 14 Jan 2005 12:53: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 j0EKrIfx048702; Fri, 14 Jan 2005 12:53:18 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0EKrGCC048630 for ; Fri, 14 Jan 2005 12:53:17 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta01-winn.mailhost.ntl.com ([212.250.162.8]) by mta10-winn.mailhost.ntl.com with ESMTP id <20050114205311.RANW15581.mta10-winn.mailhost.ntl.com@aamta01-winn.mailhost.ntl.com> for ; Fri, 14 Jan 2005 20:53:11 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta01-winn.mailhost.ntl.com with ESMTP id <20050114205311.GBAA15415.aamta01-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com> for ; Fri, 14 Jan 2005 20:53:11 +0000 Date: Fri, 14 Jan 2005 20:53:11 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <1162789013.20050114205311@djpowell.net> To: Atom Syntax Subject: atom:contributor 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 The semantics of atom:contributor weren't obvious to me. Is this correct: atom:feed/atom:head/atom:author is a syntactic default for all entries that are missing an author. atom:feed/atom:head/atom:contributor is a set of regular contributors and authors of a feed, which may or may not have contributed to, or authored entries currently in the feed. Contributors to the feed do not act as defaults for entries with missing contributors, and they are not merged with entries with missing contributors. I found the symmetry between feed authors and entry authors, and feed contributors and entry contributors a bit confusing? Did everyone else understand it? Could it do with any clarification? -- Dave From owner-atom-syntax@mail.imc.org Fri Jan 14 15:59: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 PAA16919 for ; Fri, 14 Jan 2005 15:59: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 j0EKrCdC048646; Fri, 14 Jan 2005 12:53: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 j0EKrCwT048645; Fri, 14 Jan 2005 12:53: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 j0EKrCZd048639 for ; Fri, 14 Jan 2005 12:53:12 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.9]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CpYQt-0005nT-9O; Fri, 14 Jan 2005 20:52:35 +0000 Message-ID: <41E8312A.9040509@franklinmint.fm> Date: Fri, 14 Jan 2005 15:52:58 -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: Danny Ayers CC: atom-syntax@imc.org Subject: Re: Feed, know thyself? References: <1f2ed5cd0501141237701637f9@mail.gmail.com> In-Reply-To: <1f2ed5cd0501141237701637f9@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 Danny Ayers wrote: > Thing is, with the spec as it currently stands, we don't have a link > from the feed that can be guarenteed to point to the feed URI itself. That's not a very robust way to accomplish the goal. People tend to use "cp" without thinking about these things. The browser vendors will deal with it eventually (Safari 2.0 does...) and/or we'll get a playlist type thing. That's the only way it will work reliably. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Jan 14 16:09: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 QAA19096 for ; Fri, 14 Jan 2005 16:09: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 j0EKwKiX049948; Fri, 14 Jan 2005 12:58: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 j0EKwKv3049947; Fri, 14 Jan 2005 12:58:20 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0EKwJIU049926 for ; Fri, 14 Jan 2005 12:58:19 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta05-winn.mailhost.ntl.com ([212.250.162.8]) by mta10-winn.mailhost.ntl.com with ESMTP id <20050114205813.RSOV15581.mta10-winn.mailhost.ntl.com@aamta05-winn.mailhost.ntl.com> for ; Fri, 14 Jan 2005 20:58:13 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta05-winn.mailhost.ntl.com with ESMTP id <20050114205813.QHTM769.aamta05-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com> for ; Fri, 14 Jan 2005 20:58:13 +0000 Date: Fri, 14 Jan 2005 20:58:13 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <418834319.20050114205813@djpowell.net> To: Atom Syntax Subject: Re: atom:contributor (correction) In-Reply-To: <1162789013.20050114205311@djpowell.net> References: <1162789013.20050114205311@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: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit [corrected typo] The semantics of atom:contributor weren't obvious to me. Is this correct: atom:feed/atom:head/atom:author is a syntactic default for all entries that are missing an author. atom:feed/atom:head/atom:contributor is a set of regular contributors and authors of a feed, which may or may not have contributed to, or authored entries currently in the feed. [old:] > Contributors to the feed do not act as defaults for entries with > missing contributors, and they are not merged with entries with > missing contributors. [new:] Contributors to the feed do not act as defaults for entries with missing contributors, and they are not merged with the set of contributors in an entry. I found the symmetry between feed authors and entry authors, and feed contributors and entry contributors a bit confusing? Did everyone else understand it? Could it do with any clarification? -- Dave From owner-atom-syntax@mail.imc.org Fri Jan 14 16:11: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 QAA19383 for ; Fri, 14 Jan 2005 16:11: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 j0EKxDF7050074; Fri, 14 Jan 2005 12: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 j0EKxDgu050073; Fri, 14 Jan 2005 12:59:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from imo-d22.mx.aol.com (imo-d22.mx.aol.com [205.188.144.208]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0EKxBg6050051 for ; Fri, 14 Jan 2005 12:59:12 -0800 (PST) (envelope-from panzerjohn@aol.com) Received: from panzerjohn@aol.com by imo-d22.mx.aol.com (mail_out_v37_r3.8.) id o.1d9.3435336f (15874); Fri, 14 Jan 2005 15:59:00 -0500 (EST) Received: from h-10-169-155-195.nscp.aoltw.net (h-10-169-155-195.nscp.aoltw.net [10.169.155.195]) by air-id07.mx.aol.com (v104.17) with ESMTP id MAILINID71-3e0241e832932fb; Fri, 14 Jan 2005 15:59:00 -0500 Date: Fri, 14 Jan 2005 12:58:59 -0800 From: "John Panzer" Reply-To: jpanzer@aol.net Subject: Re: Feed, know thyself? To: "Danny Ayers" cc: atom-syntax@imc.org In-Reply-To: <1f2ed5cd0501141237701637f9@mail.gmail.com> Message-ID: <41E83293.3030809@aol.com> References: <1f2ed5cd0501141237701637f9@mail.gmail.com> X-Mailer: AOL Communicator (20030919.3 Win) Organization: AOL MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii X-AOL-IP: 10.169.155.195 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hmmm. Not looking at the spec, but at the feeds we're currently producting for AOL Journals, our feeds have essentially pointing to themselves, which I yesterday thought was redundant but perhaps is actually useful. Useful enough to be mandatory, perhaps? -John Danny Ayers wrote on 1/14/2005, 12:37 PM: > > I was just in the middle of putting the world to rights regarding feed > discovery/subscription from browsers [1] when something occurred to > me. Correct me if I'm wrong, but isn't one of the solutions for this > to serve the feed with the Atom mime type, which will trigger an > appropriate handler in the browser? > > If I remember correctly from previous discussions, there is a little > snag with most browsers only passing the data, not the source URI. > Thing is, with the spec as it currently stands, we don't have a link > from the feed that can be guarenteed to point to the feed URI itself. > Having the handler go back to a HTML page to do autodiscovery seems a > little roundabout. Relevant spec bit pasted below. > > Thoughts? > > Cheers, > Danny. > > > 4.2.2 "atom:link" Element > > The "atom:link" element is a Link construct that conveys a URI > associated with the feed. The nature of the relationship is > determined by the construct's rel attribute. > > atom:head elements MUST contain at least one atom:link element with a > rel attribute value of "alternate". > > atom:head elements MUST NOT contain more than one atom:link element > with a rel attribute value of "alternate" that has the same type > attribute value. > > [1] http://danja.typepad.com/uncooked/2005/01/life_the_univer.html > > > -- > > http://dannyayers.com > -- John Panzer | Sr Technical Manager, AOL Blog: http://journals.aol.com/panzerjohn/abstractioneer From owner-atom-syntax@mail.imc.org Fri Jan 14 16:59: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 QAA29130 for ; Fri, 14 Jan 2005 16:59: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 j0ELiRQW063781; Fri, 14 Jan 2005 13:44: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 j0ELiRrA063780; Fri, 14 Jan 2005 13:44:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vspmail.nscp.aoltw.net (h-64-236-139-249.aoltw.net [64.236.139.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0ELiNvR063769 for ; Fri, 14 Jan 2005 13:44:27 -0800 (PST) (envelope-from jpanzer@AOL.NET) Received: from h-10-169-155-195.nscp.aoltw.net (h-10-169-155-195.nscp.aoltw.net [10.169.155.195]) by vspmail.nscp.aoltw.net (8.11.6/8.11.6) with ESMTP id j0ELptR00630 for ; Fri, 14 Jan 2005 13:51:55 -0800 Date: Fri, 14 Jan 2005 13:44:13 -0800 From: "John Panzer" Subject: Re: Feed, know thyself? To: atom-syntax Message-ID: <41E83D2D.6080001@AOL.NET> X-Mailer: AOL Communicator (20030919.3 Win) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hmmm. Not looking at the spec, but at the feeds we're currently producting for AOL Journals, our feeds have essentially pointing to themselves, which I yesterday thought was redundant but perhaps is actually useful. Useful enough to be mandatory, perhaps? -John Danny Ayers wrote on 1/14/2005, 12:37 PM: > > I was just in the middle of putting the world to rights regarding feed > discovery/subscription from browsers [1] when something occurred to > me. Correct me if I'm wrong, but isn't one of the solutions for this > to serve the feed with the Atom mime type, which will trigger an > appropriate handler in the browser? > > If I remember correctly from previous discussions, there is a little > snag with most browsers only passing the data, not the source URI. > Thing is, with the spec as it currently stands, we don't have a link > from the feed that can be guarenteed to point to the feed URI itself. > Having the handler go back to a HTML page to do autodiscovery seems a > little roundabout. Relevant spec bit pasted below. > > Thoughts? > > Cheers, > Danny. > > > 4.2.2 "atom:link" Element > > The "atom:link" element is a Link construct that conveys a URI > associated with the feed. The nature of the relationship is > determined by the construct's rel attribute. > > atom:head elements MUST contain at least one atom:link element with a > rel attribute value of "alternate". > > atom:head elements MUST NOT contain more than one atom:link element > with a rel attribute value of "alternate" that has the same type > attribute value. > > [1] http://danja.typepad.com/uncooked/2005/01/life_the_univer.html > > > -- > > http://dannyayers.com > -- John Panzer | Sr Technical Manager, AOL Blog: http://journals.aol.com/panzerjohn/abstractioneer -- John Panzer | Sr Technical Manager, AOL Blog: http://journals.aol.com/panzerjohn/abstractioneer From owner-atom-syntax@mail.imc.org Fri Jan 14 21:40: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 VAA18524 for ; Fri, 14 Jan 2005 21:40: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 j0F2ISXe087486; Fri, 14 Jan 2005 18:18: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 j0F2ISG9087485; Fri, 14 Jan 2005 18:18:28 -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 j0F2IQMB086391 for ; Fri, 14 Jan 2005 18:18:27 -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, 15 Jan 2005 15:18:36 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 15 Jan 2005 13:17:53 +1100 Subject: Re: Feed, know thyself? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1f2ed5cd0501141237701637f9@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 15/1/05 7:37 AM, "Danny Ayers" wrote: > If I remember correctly from previous discussions, there is a little > snag with most browsers only passing the data, not the source URI. > Thing is, with the spec as it currently stands, we don't have a link > from the feed that can be guarenteed to point to the feed URI itself. > Having the handler go back to a HTML page to do autodiscovery seems a > little roundabout. +1 to having a self-referential link to the preferred URL for subscription. Not only does it help with the "browser passes content only to handler specified by mime-type" situation, but it also helps to avoid accidental/nutty aliases from propogating (eg. http://example.com/feed.atom vs http://203.xxx.xxx.xxx/feed.atom, where both actually point to the same feed) We need an appropriate @rel value (to put into the spec and the registry). Prior art suggests "bookmark". e. From owner-atom-syntax@mail.imc.org Fri Jan 14 22:48: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 WAA23140 for ; Fri, 14 Jan 2005 22:48: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 j0F3ZLI6045797; Fri, 14 Jan 2005 19:35: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 j0F3ZLdI045795; Fri, 14 Jan 2005 19:35: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.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0F3ZG2s045565 for ; Fri, 14 Jan 2005 19:35:16 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id b11so36009rne for ; Fri, 14 Jan 2005 19:35: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:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=brZIztvPzxasPwMdkxoDj3N8grxzz2n5J4FPKM2YSwfE5SH4d+EJKRfTww3K4lyoy2xAu3W0dC4xTLb4tUXZG5ksy5D/PWmAuGJNtwgrdhjBN6x3ez4cLzv8SF/p0hmoxJWaZxo1uN/lgVVePH5K7Id9ysaF8duMGBC+o+R+nNQ= Received: by 10.38.158.11 with SMTP id g11mr137580rne; Fri, 14 Jan 2005 19:35:11 -0800 (PST) Received: by 10.38.151.21 with HTTP; Fri, 14 Jan 2005 19:35:10 -0800 (PST) Message-ID: <3f1451f5050114193552d10d40@mail.gmail.com> Date: Fri, 14 Jan 2005 22:35:10 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: jpanzer@aol.net Subject: Re: Feed, know thyself? Cc: Danny Ayers , atom-syntax@imc.org In-Reply-To: <41E83293.3030809@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd0501141237701637f9@mail.gmail.com> <41E83293.3030809@aol.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 14 Jan 2005 12:58:59 -0800, John Panzer wrote: > > Hmmm. Not looking at the spec, but at the feeds we're currently > producting for AOL Journals, our feeds have ...> essentially pointing to themselves, which I yesterday thought was > redundant but perhaps is actually useful. Useful enough to be > mandatory, perhaps? Yes, being mandatory would be helpful: http://bitworking.org/news/Atom_Auto_Sub_How_To -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Sat Jan 15 04:31: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 EAA26012 for ; Sat, 15 Jan 2005 04:31: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 j0F95QUg041394; Sat, 15 Jan 2005 01:05: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 j0F95QvK041392; Sat, 15 Jan 2005 01:05: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.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0F95LZp041232 for ; Sat, 15 Jan 2005 01:05:22 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 1so1177328rny for ; Sat, 15 Jan 2005 01:05: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=VT0OnSsSDmJ/tfEGFGReQGZatSFxBj9Zs7lAZeSRnxiptg9LK20iVcCG16PdsAylrg0bRGwCWN2iMN8X8QiuIQJwBUn0fCcx6r9uzsTXQZF6XbaggJS9SEEH9JydiW8C4vxyiztK0pBNcKByooauxBKIs56RPZhRlD5wraedSGE= Received: by 10.38.179.33 with SMTP id b33mr395800rnf; Sat, 15 Jan 2005 01:05:19 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sat, 15 Jan 2005 01:05:19 -0800 (PST) Message-ID: <1f2ed5cd05011501051f29a0bc@mail.gmail.com> Date: Sat, 15 Jan 2005 10:05:19 +0100 From: Danny Ayers Reply-To: Danny Ayers To: mint@franklinmint.fm Subject: Re: Feed, know thyself? Cc: atom-syntax@imc.org In-Reply-To: <41E8312A.9040509@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd0501141237701637f9@mail.gmail.com> <41E8312A.9040509@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 14 Jan 2005 15:52:58 -0500, Robert Sayre wrote: > Danny Ayers wrote: > > > Thing is, with the spec as it currently stands, we don't have a link > > from the feed that can be guarenteed to point to the feed URI itself. > > That's not a very robust way to accomplish the goal. People tend to use > "cp" without thinking about these things. Do they? I've done HTTP redirects often enough (had to yesterday, coincidentally) but don't recall ever having to do anything that would break a source reference. The browser vendors will deal > with it eventually (Safari 2.0 does...) and/or we'll get a playlist type > thing. That's the only way it will work reliably. Maybe, but right now the leading browser doesn't deal with it, it's not clear they even have any motivation to. Seems to me like making a source-URI reference a SHOULD would help solve an immediate problem, irrespective of the hypothetical problem of copying. Is a Pace needed? (Where is the time???) Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Jan 15 11:59: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 LAA23065 for ; Sat, 15 Jan 2005 11:59: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 j0FGbhmZ022002; Sat, 15 Jan 2005 08:37: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 j0FGbhFC022001; Sat, 15 Jan 2005 08:37: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 j0FGbdxu021985 for ; Sat, 15 Jan 2005 08:37:39 -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 j0FGbddt027981 for ; Sat, 15 Jan 2005 09:37: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 <0IAD00KKHA6Q5Q@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 15 Jan 2005 09:37:39 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAD0076EA6QOP@mail.sun.net> for atom-syntax@imc.org; Sat, 15 Jan 2005 09:37:38 -0700 (MST) Date: Sat, 15 Jan 2005 08:37:47 -0800 From: Tim Bray Subject: Re: Feed, know thyself? In-reply-to: <1f2ed5cd05011501051f29a0bc@mail.gmail.com> To: Danny Ayers Cc: mint@franklinmint.fm, 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: <1f2ed5cd0501141237701637f9@mail.gmail.com> <41E8312A.9040509@franklinmint.fm> <1f2ed5cd05011501051f29a0bc@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 15, 2005, at 1:05 AM, Danny Ayers wrote: > Seems to me like making a source-URI reference a SHOULD would help > solve an immediate problem, irrespective of the hypothetical problem > of copying. I see no downside. There are going to be scenarios where it's not reliable, but there are going to be lots where it's useful. > Is a Pace needed? Yes. -Tim From owner-atom-syntax@mail.imc.org Sat Jan 15 12:41: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 MAA25920 for ; Sat, 15 Jan 2005 12:40: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 j0FHUsKr027883; Sat, 15 Jan 2005 09:30: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 j0FHUsi5027882; Sat, 15 Jan 2005 09:30:54 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0FHUrUQ027871 for ; Sat, 15 Jan 2005 09:30:53 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta01-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050115173047.TJIM4706.mta08-winn.mailhost.ntl.com@aamta01-winn.mailhost.ntl.com> for ; Sat, 15 Jan 2005 17:30:47 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta01-winn.mailhost.ntl.com with ESMTP id <20050115173047.PJMO15415.aamta01-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com> for ; Sat, 15 Jan 2005 17:30:47 +0000 Date: Sat, 15 Jan 2005 17:30:47 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <1863472781.20050115173047@djpowell.net> To: Atom Syntax Subject: Posted PaceSimpleLanguageTagging 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 PaceExtensionConstruct hopes to provide a basis for a mapping Atom to models such as RDF [1], ER, and OO. I'm currently doing some work to see whether there is anything in Atom that makes this unnecessarily difficult. I think that Atom's use of xml:lang is likely to be a significant problem to many implementors. I've posted PaceSimpleLanguageTagging explaining the problem. http://www.intertwingly.net/wiki/pie/PaceSimpleLanguageTagging [1] RDF supports language tagging of literals, so xml:lang doesn't actually cause a serious problem for an Atom implementation based on an RDF model. -- Dave From owner-atom-syntax@mail.imc.org Sat Jan 15 14: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 OAA00714 for ; Sat, 15 Jan 2005 14: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 j0FIr6C3040364; Sat, 15 Jan 2005 10:53: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 j0FIr6Zj040363; Sat, 15 Jan 2005 10:53:06 -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 j0FIr6fD040353 for ; Sat, 15 Jan 2005 10:53:06 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 1so1200540rny for ; Sat, 15 Jan 2005 10:53:02 -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=JL2cCzSsrLma85LxJXe4y0lpPJ2qdpmk1OABhukzdcdshaeehbagRfY4Ir6yq+7nyWHhNbWJYVMMLtxdPg6s60Ld6VLA4bBp4uj4dkBUoYxBlNfej02zYdxtcx8OFYPeXi7NegUFp7wfVRpxbU5ZG+DS5805fI1Wkq2lEe2yNnk= Received: by 10.38.8.48 with SMTP id 48mr85954rnh; Sat, 15 Jan 2005 10:53:02 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sat, 15 Jan 2005 10:53:02 -0800 (PST) Message-ID: <1f2ed5cd05011510535cb52f89@mail.gmail.com> Date: Sat, 15 Jan 2005 19:53:02 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: Feed, know thyself? Cc: mint@franklinmint.fm, atom-syntax@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd0501141237701637f9@mail.gmail.com> <41E8312A.9040509@franklinmint.fm> <1f2ed5cd05011501051f29a0bc@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 15 Jan 2005 08:37:47 -0800, Tim Bray wrote: > On Jan 15, 2005, at 1:05 AM, Danny Ayers wrote: > > > Seems to me like making a source-URI reference a SHOULD would help > > solve an immediate problem, irrespective of the hypothetical problem > > of copying. > > I see no downside. There are going to be scenarios where it's not > reliable, but there are going to be lots where it's useful. > > > Is a Pace needed? > > Yes. -Tim [expletive deleted]! Ok, I'll try and sort it tomorrow. I'm sure extensibility is in good hands... Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Jan 15 14:01: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 OAA00842 for ; Sat, 15 Jan 2005 14:01: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 j0FIlPJY036820; Sat, 15 Jan 2005 10:47: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 j0FIlPOb036819; Sat, 15 Jan 2005 10:47:25 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0FIlOrR036800 for ; Sat, 15 Jan 2005 10:47:24 -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 <20050115184718.RPLC15581.mta10-winn.mailhost.ntl.com@aamta02-winn.mailhost.ntl.com> for ; Sat, 15 Jan 2005 18:47:18 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta02-winn.mailhost.ntl.com with ESMTP id <20050115184718.HQLM3760.aamta02-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com> for ; Sat, 15 Jan 2005 18:47:18 +0000 Date: Sat, 15 Jan 2005 18:47:17 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <1758320721.20050115184717@djpowell.net> To: atom-syntax@imc.org Subject: Re: Posted PaceExtensionConstruct In-Reply-To: <1113271276.20050112211950@djpowell.net> References: <1113271276.20050112211950@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: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I've just updated this proposal thanks to some of the feedback that I received. There is a change history at the end of the document. http://www.intertwingly.net/wiki/pie/PaceExtensionConstruct -- Dave From owner-atom-syntax@mail.imc.org Sat Jan 15 14:13: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 OAA01517 for ; Sat, 15 Jan 2005 14:13: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 j0FJ6fb0041828; Sat, 15 Jan 2005 11:06: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 j0FJ6f1v041827; Sat, 15 Jan 2005 11:06: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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0FJ6eHQ041821 for ; Sat, 15 Jan 2005 11:06:41 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 1so1201119rny for ; Sat, 15 Jan 2005 11:06:40 -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=owx5iBEPJVYybcsMmFJJS27ExMRHkZfqoojpgTD0E7k9mDXllwfigFN9CJj6COEtZ3ecqGc1mlDI8GHu6ScE/LtNeEUT+5p5NEh0F/oGSLyxxhkUCHYJ/CdVIB1wMuAX8vokmPlsDLVOlFirK5f6dcaM/YnL4Tzble1xx3PRaR0= Received: by 10.38.206.10 with SMTP id d10mr157974rng; Sat, 15 Jan 2005 11:06:40 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sat, 15 Jan 2005 11:06:40 -0800 (PST) Message-ID: <1f2ed5cd05011511065163933@mail.gmail.com> Date: Sat, 15 Jan 2005 20:06:40 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Robert Sayre Subject: Re: Feed, know thyself? Cc: Tim Bray , atom-syntax@imc.org In-Reply-To: <41E96800.2080109@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd0501141237701637f9@mail.gmail.com> <41E8312A.9040509@franklinmint.fm> <1f2ed5cd05011501051f29a0bc@mail.gmail.com> <41E96800.2080109@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 15 Jan 2005 13:59:12 -0500, Robert Sayre wrote: > Tim Bray wrote: > > On Jan 15, 2005, at 1:05 AM, Danny Ayers wrote: > > > >> Seems to me like making a source-URI reference a SHOULD would help > >> solve an immediate problem, irrespective of the hypothetical problem > >> of copying. > > > > > > I see no downside. There are going to be scenarios where it's not > > reliable, but there are going to be lots where it's useful. > > > > Well, it does make it easy for me to put entries in your feed. ...and to confirm they weren't there to start with. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Jan 15 14:16: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 OAA01594 for ; Sat, 15 Jan 2005 14: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 j0FIxPhh040985; Sat, 15 Jan 2005 10:59: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 j0FIxPr4040984; Sat, 15 Jan 2005 10:59: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 j0FIxOEI040968 for ; Sat, 15 Jan 2005 10:59:25 -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 1Cpt8A-0001zz-54; Sat, 15 Jan 2005 18:58:38 +0000 Message-ID: <41E96800.2080109@franklinmint.fm> Date: Sat, 15 Jan 2005 13:59:12 -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: Danny Ayers , atom-syntax@imc.org Subject: Re: Feed, know thyself? References: <1f2ed5cd0501141237701637f9@mail.gmail.com> <41E8312A.9040509@franklinmint.fm> <1f2ed5cd05011501051f29a0bc@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: > On Jan 15, 2005, at 1:05 AM, Danny Ayers wrote: > >> Seems to me like making a source-URI reference a SHOULD would help >> solve an immediate problem, irrespective of the hypothetical problem >> of copying. > > > I see no downside. There are going to be scenarios where it's not > reliable, but there are going to be lots where it's useful. > Well, it does make it easy for me to put entries in your feed. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Jan 15 14: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 OAA01759 for ; Sat, 15 Jan 2005 14: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 j0FJGj8f042874; Sat, 15 Jan 2005 11:16: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 j0FJGjoK042873; Sat, 15 Jan 2005 11:16: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 j0FJGj2E042864 for ; Sat, 15 Jan 2005 11:16:45 -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 1CptP2-0002Bg-8U; Sat, 15 Jan 2005 19:16:04 +0000 Message-ID: <41E96C15.1080603@franklinmint.fm> Date: Sat, 15 Jan 2005 14:16:37 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Tim Bray , atom-syntax@imc.org Subject: Re: Feed, know thyself? References: <1f2ed5cd0501141237701637f9@mail.gmail.com> <41E8312A.9040509@franklinmint.fm> <1f2ed5cd05011501051f29a0bc@mail.gmail.com> <41E96800.2080109@franklinmint.fm> <1f2ed5cd05011511065163933@mail.gmail.com> In-Reply-To: <1f2ed5cd05011511065163933@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 Danny Ayers wrote: > On Sat, 15 Jan 2005 13:59:12 -0500, Robert Sayre wrote: > >>Tim Bray wrote: >> >>>On Jan 15, 2005, at 1:05 AM, Danny Ayers wrote: >>> >>> >>>>Seems to me like making a source-URI reference a SHOULD would help >>>>solve an immediate problem, irrespective of the hypothetical problem >>>>of copying. >>> >>> >>>I see no downside. There are going to be scenarios where it's not >>>reliable, but there are going to be lots where it's useful. >>> >> >>Well, it does make it easy for me to put entries in your feed. > > > ...and to confirm they weren't there to start with. How so? Do I go back and confirm with the server? Why did I downoad a whole feed to do that? Maybe it's changed. What does it mean if I retrieve at a feed a URI and it's not the same one? This creates a unique situation for users, where they can download a feed, but possibly not subscribe to it. It's also a whole new class of bugs, and I'm having trouble thinking of all of them. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Jan 15 15:09: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 PAA02474 for ; Sat, 15 Jan 2005 15:09: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 j0FJtcRF049681; Sat, 15 Jan 2005 11:55: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 j0FJtciq049680; Sat, 15 Jan 2005 11:55: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.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0FJtcJk049661 for ; Sat, 15 Jan 2005 11:55:38 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 1so1203401rny for ; Sat, 15 Jan 2005 11:55: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:mime-version:content-type:content-transfer-encoding; b=J5RXKAipaD09NpKYBlLVN1UEy/UW0wj+fBdy6qtW8tKHEdMTb9TfJ7n9PzT149l4uYtoMB5MEYVVuSoS/KWh/s8LRUtgLhKFnySaeVmtJmGz7qlyLc1mOe++sX1o+F/O5CSOXMobVe00bB0RI7JEU3dWEl8zKxETHeyEkuUmxvg= Received: by 10.38.8.48 with SMTP id 48mr100256rnh; Sat, 15 Jan 2005 11:55:34 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sat, 15 Jan 2005 11:55:34 -0800 (PST) Message-ID: <1f2ed5cd050115115541ceec0c@mail.gmail.com> Date: Sat, 15 Jan 2005 20:55:34 +0100 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: PaceFeedLink 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 First pass (this is what should be on the Wiki - it decided to lock me out): #pragma section-numbers off == Abstract == Adds a element in pointing to the feed itself, primarily to enable subscription based on the XML alone. == Status == Open. == Rationale == When processing a HTTP response with a known MIME type for which an external handler is registered, few browsers pass on the source URI to the handler. This information will be required by most client applications, in particular for aggregators to subscribe to the feed. Being able to identify the source of a feed through the feed itself may also be helpful in provenance tracking. Moves Atom a little closer to feature-parity with RSS 1.0 (rss:channel resource) == Proposal == An option for the link rel value of "self" to be added to the registry. The following to be appended to Section 4.2.2 (atom:link inside atom:head): {{{ atom:head elements SHOULD contain one atom:link element with a rel attribute value of "self" and SHOULD contain a href attribute with an absolute URI as its value. This URI SHOULD identify the feed and a representation exactly equivalent to the feed SHOULD be available through a HTTP GET on the URI. If the link has a "type" attribute, its value MUST conform to the Atom MIME type as described in Section 10. The atom:link element MUST otherwise conform to the definition of a Link Construct in Section 3.5. }}} == Impacts == Adds another element to the feed. Adds an entry to the registy. == Notes == ---- CategoryProposals -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Jan 15 15: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 PAA02894 for ; Sat, 15 Jan 2005 15: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 j0FK3RCT050819; Sat, 15 Jan 2005 12:03: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 j0FK3R1W050818; Sat, 15 Jan 2005 12:03: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.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0FK3Rns050808 for ; Sat, 15 Jan 2005 12:03:27 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 1so1203734rny for ; Sat, 15 Jan 2005 12:03:22 -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=lu9LrnXezXF8LXoeCXc96Zjt46LaeBqjWSb4ozM7Uf/Zq8AN6Hf7OMp588yXwR6EZViIHiUf+IbDpKExkuzIXn8PbQIpjKece8wRmilJ9T7ubNuItsNuWhlSJ8RzuIH2M6z5t4Qpbcrh4aehaIhW1PfbCgcuOb3P9PieTyE9pUM= Received: by 10.38.206.10 with SMTP id d10mr170710rng; Sat, 15 Jan 2005 12:03:21 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sat, 15 Jan 2005 12:03:21 -0800 (PST) Message-ID: <1f2ed5cd05011512036a83fb6f@mail.gmail.com> Date: Sat, 15 Jan 2005 21:03:21 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Robert Sayre Subject: Re: Feed, know thyself? Cc: Tim Bray , atom-syntax@imc.org In-Reply-To: <41E96C15.1080603@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd0501141237701637f9@mail.gmail.com> <41E8312A.9040509@franklinmint.fm> <1f2ed5cd05011501051f29a0bc@mail.gmail.com> <41E96800.2080109@franklinmint.fm> <1f2ed5cd05011511065163933@mail.gmail.com> <41E96C15.1080603@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 15 Jan 2005 14:16:37 -0500, Robert Sayre wrote: > >>Well, it does make it easy for me to put entries in your feed. > > > > > > ...and to confirm they weren't there to start with. > > How so? Do I go back and confirm with the server? Why did I downoad a > whole feed to do that? You may want to check a mirror/proxy. Maybe it's changed. What does it mean if I > retrieve at a feed a URI and it's not the same one? You know the original data is either out-of-date or untrustworthy. > This creates a unique situation for users, where they can download a > feed, but possibly not subscribe to it. Right now there's no way to subscribe from say IE. > It's also a whole new class of bugs, and I'm having trouble thinking of > all of them. No, this is already possible with RSS 1.0. If you build new applications, then you may start to introduce new bugs. There may be reasons why this isn't a good idea, but these issues all still seem very hypothetical, whereas the potential benefit is fairly tangible. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Jan 15 15:25: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 PAA03805 for ; Sat, 15 Jan 2005 15:25: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 j0FKFooe052298; Sat, 15 Jan 2005 12:15: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 j0FKFoZP052297; Sat, 15 Jan 2005 12:15: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 j0FKFoLE052291 for ; Sat, 15 Jan 2005 12:15:50 -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 1CpuKD-0002iy-UD; Sat, 15 Jan 2005 20:15:10 +0000 Message-ID: <41E979F2.8070906@franklinmint.fm> Date: Sat, 15 Jan 2005 15:15:46 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Tim Bray , atom-syntax@imc.org Subject: Re: Feed, know thyself? References: <1f2ed5cd0501141237701637f9@mail.gmail.com> <41E8312A.9040509@franklinmint.fm> <1f2ed5cd05011501051f29a0bc@mail.gmail.com> <41E96800.2080109@franklinmint.fm> <1f2ed5cd05011511065163933@mail.gmail.com> <41E96C15.1080603@franklinmint.fm> <1f2ed5cd05011512036a83fb6f@mail.gmail.com> In-Reply-To: <1f2ed5cd05011512036a83fb6f@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 Danny Ayers wrote: > >>This creates a unique situation for users, where they can download a >>feed, but possibly not subscribe to it. > > > Right now there's no way to subscribe from say IE. > That's not the point. That does not result in a support call to the aggregator vendor, because it's IE's problem. Right now, once the user gets the URI to the aggregator somehow, things tend to work. This proposal introduces a situation where the feed can show up in the aggregator and appear broken. As such, it would be foolish to implement this in an aggregator. > >>It's also a whole new class of bugs, and I'm having trouble thinking of >>all of them. > > > No, this is already possible with RSS 1.0. Really? How is it done? Robert Sayre From owner-atom-syntax@mail.imc.org Sat Jan 15 15: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 PAA04131 for ; Sat, 15 Jan 2005 15: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 j0FKLZoC052954; Sat, 15 Jan 2005 12:21: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 j0FKLZaP052953; Sat, 15 Jan 2005 12:21:35 -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 j0FKLYGF052927 for ; Sat, 15 Jan 2005 12:21:35 -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 j0FKLQqn015939; Sat, 15 Jan 2005 15:21:26 -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 CIZ42412; Sat, 15 Jan 2005 15:21:25 -0500 (EST) Message-Id: <200501152021.CIZ42412@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Danny Ayers'" , Subject: RE: Feed, know thyself? Date: Sat, 15 Jan 2005 15:21:23 -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: <1f2ed5cd0501141237701637f9@mail.gmail.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcT6fFMVnPZmisn0Qnmgji+pX/XiFAAwcoJg Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > we don't have a link from the feed that can be guarenteed to point > to the feed URI itself. If these links were in the feed's element it would make life easier for us at PubSub.com. We currently insert a link pointing to the source feed into every entry that we insert into one of our synthetic feeds. We do this for both RSS and Atom. It should be noted, however, that there are potentially two "source" feed links that are interesting. When an aggregator is in use, you could have the "source" link that is reported by the feed itself and you could have a different source URI which would be the URI at which the feed was actually discovered. At PubSub.com, we'll probably want to report both of these -- particularly if they differ. The difference between these two URI's can, of course, have a number of different causes. These include: 1) Typographical error by the feed owner when inserting the source URI. 2) The feed might have been copied to a location other then the location it was intended to have when first created and when the source URI was written. 3) Feeds might be stored in locations that have multiple equivalent names. For instance, the feed might have a URI whose "host" field is a domain name, yet, the feed was retrieved using an IP address as the "host" (i.e. pubsub.com vs "209.11.36.154" -- both equivelant.) The same sort of multiple naming can result from symlinks, multi-hosting servers, etc. bob wyman From owner-atom-syntax@mail.imc.org Sat Jan 15 15:37: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 PAA04319 for ; Sat, 15 Jan 2005 15:37: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 j0FKSuER053704; Sat, 15 Jan 2005 12:28: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 j0FKSuTJ053703; Sat, 15 Jan 2005 12:28: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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0FKSsVU053690 for ; Sat, 15 Jan 2005 12:28:55 -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 <20050115202849.RVBX10495.mta13-winn.mailhost.ntl.com@aamta07-winn.mailhost.ntl.com>; Sat, 15 Jan 2005 20:28:49 +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 <20050115202849.KBGJ8064.aamta07-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Sat, 15 Jan 2005 20:28:49 +0000 Date: Sat, 15 Jan 2005 20:28:48 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <1943024938.20050115202848@djpowell.net> To: Robert Sayre CC: Tim Bray , Danny Ayers , atom-syntax@imc.org Subject: Re: Feed, know thyself? In-Reply-To: <41E96800.2080109@franklinmint.fm> References: <1f2ed5cd0501141237701637f9@mail.gmail.com> <41E8312A.9040509@franklinmint.fm> <1f2ed5cd05011501051f29a0bc@mail.gmail.com> <41E96800.2080109@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 Saturday, January 15, 2005, 6:59:12 PM, you wrote: > Tim Bray wrote: >> On Jan 15, 2005, at 1:05 AM, Danny Ayers wrote: >> >>> Seems to me like making a source-URI reference a SHOULD would help >>> solve an immediate problem, irrespective of the hypothetical problem >>> of copying. >> >> >> I see no downside. There are going to be scenarios where it's not >> reliable, but there are going to be lots where it's useful. >> > Well, it does make it easy for me to put entries in your feed. > Robert Sayre Would something like this fix it? It might require the feed to be fetched twice, but it is only at subscription time. BTW - Is it really impossible to obtain the location that a feed was fetched from on IE/Win? IE manages it for CDF files, and I believe that Acrobat files are streamed by Acrobat when you click on link. 11.1 Verifying the Authenticity of Self Links If an atom:head element contains a Link construct where the "rel" attribute is "self", software processing the document SHOULD NOT assume that the URI specified by the "href" attribute is genuine unless the software can confirm that the URI matches the URI that the document was obtained from. Software that cannot verify the authenticity of the self link, SHOULD refetch the Atom document using the self link. -- Dave From owner-atom-syntax@mail.imc.org Sat Jan 15 15:38: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 PAA04341 for ; Sat, 15 Jan 2005 15:38: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 j0FKUKd2053857; Sat, 15 Jan 2005 12:30: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 j0FKUKBi053856; Sat, 15 Jan 2005 12:30:20 -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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0FKUJCG053831 for ; Sat, 15 Jan 2005 12:30:19 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 1so1204954rny for ; Sat, 15 Jan 2005 12:30:14 -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=LaBZ3Zo5eZwMMJZ4CJdrSGCA7qtN9iB0PPtPwfe0voaq7XiX1q9d4HDB5KmD0RQk/RLKBqN4fIILZ0KqfC1flAUTYqxF7/YmUy2aAIdUXMAZ4QxfBRUhSvh2wWU0Qj4CzscGI2ocBhOEB60GPNA4Ho01p8yN3N2yYdmsA07f0Is= Received: by 10.38.179.48 with SMTP id b48mr490817rnf; Sat, 15 Jan 2005 12:30:14 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sat, 15 Jan 2005 12:30:14 -0800 (PST) Message-ID: <1f2ed5cd050115123075ce258a@mail.gmail.com> Date: Sat, 15 Jan 2005 21:30:14 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Robert Sayre Subject: Re: Feed, know thyself? Cc: Tim Bray , atom-syntax@imc.org In-Reply-To: <41E979F2.8070906@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd0501141237701637f9@mail.gmail.com> <41E8312A.9040509@franklinmint.fm> <1f2ed5cd05011501051f29a0bc@mail.gmail.com> <41E96800.2080109@franklinmint.fm> <1f2ed5cd05011511065163933@mail.gmail.com> <41E96C15.1080603@franklinmint.fm> <1f2ed5cd05011512036a83fb6f@mail.gmail.com> <41E979F2.8070906@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 15 Jan 2005 15:15:46 -0500, Robert Sayre wrote: > > No, this is already possible with RSS 1.0. > > Really? How is it done? My apologies, the RSS 1.0 spec actually says the rss:channel resource is "...either the URL of the homepage being described or a URL where the RSS file can be found." -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Jan 15 16:05: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 QAA04569 for ; Sat, 15 Jan 2005 16:05: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 j0FKrTFO062750; Sat, 15 Jan 2005 12:53: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 j0FKrTnK062745; Sat, 15 Jan 2005 12:53:29 -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 j0FKrScJ062601 for ; Sat, 15 Jan 2005 12:53:28 -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 j0FKqd55001778; Sat, 15 Jan 2005 20:52:49 GMT In-Reply-To: <1943024938.20050115202848@djpowell.net> References: <1f2ed5cd0501141237701637f9@mail.gmail.com> <41E8312A.9040509@franklinmint.fm> <1f2ed5cd05011501051f29a0bc@mail.gmail.com> <41E96800.2080109@franklinmint.fm> <1943024938.20050115202848@djpowell.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-24-813624660; protocol="application/pkcs7-signature" Message-Id: <64EE2313-6737-11D9-8584-000A95DC3D90@mac.com> Cc: Atom Syntax From: Graham Subject: Re: Feed, know thyself? Date: Sat, 15 Jan 2005 20:52:39 +0000 To: David Powell X-Mailer: Apple Mail (2.619) 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-24-813624660 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 15 Jan 2005, at 8:28 pm, David Powell wrote: > 11.1 Verifying the Authenticity of Self Links Can someone explain the attack model here? The worst that I can see happening is that when you try to subscribe to my feed, you end up subscribed to someone else's. How does this harm anyone but me? Graham --Apple-Mail-24-813624660 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 9w0BCQUxDxcNMDUwMTE1MjA1MjQwWjAjBgkqhkiG9w0BCQQxFgQUJif+4NX3lJcypRerREoW/u1H mh4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEA3nDmraReiuaPaIUT+Xt4JQR6 42095KOiqXMicrVbAletrK1/cr9YjAjYjkbtFG6WERzG0c/9wG30rL3syK7OsR27nNp5XCoww5qT 8xcwAhukxeAdt5/kTDld6L+U28cyboRcXlFjLTlfQK+p+B6skJL0a9Q91FUpDk/tbU6H4D1/4GZj XVlENQtXlR0KVQ+0YDWijqdpS2sZ3z6CnnsG4aS1sk5FE8QcfPOu1ugl27WIx7m7kwBhXDygSHhU rDIiTIkpkSRv9OchUU08cuTRJBZmkdeKCGl3DAQ/og7Dm9FJlQoh1TOoZ8TCLdZyThDHqmOxK868 7JZjehilh6iHLQAAAAAAAA== --Apple-Mail-24-813624660-- From owner-atom-syntax@mail.imc.org Sat Jan 15 16:33: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 QAA04964 for ; Sat, 15 Jan 2005 16:33: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 j0FLDnre090009; Sat, 15 Jan 2005 13:13: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 j0FLDneT090008; Sat, 15 Jan 2005 13:13:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout1.netvision.net.il (mxout1.netvision.net.il [194.90.9.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0FLDlRu089785 for ; Sat, 15 Jan 2005 13:13:48 -0800 (PST) (envelope-from zivca@netvision.net.il) Received: from zivchome ([62.0.66.69]) by mxout1.netvision.net.il (Sun Java System Messaging Server 6.1 HotFix 0.06 (built Nov 11 2004)) with ESMTPA id <0IAD0024CMXWP0B0@mxout1.netvision.net.il> for atom-syntax@imc.org; Sat, 15 Jan 2005 23:13:31 +0200 (IST) Date: Sat, 15 Jan 2005 23:12:57 +0200 From: Ziv Caspi Subject: RE: Please Review: Dissemination of Earthquake / Tsunami data via Atom In-reply-to: <200501102124.CHX73621@ms8.netsolmail.com> To: bob@wyman.us, "'Atom Syntax'" Message-id: <000001c4fb47$0b206a20$4542003e@zivchome> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=iso-8859-1 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0FLDmRu090001 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bob Wyman: [[[ I am particularly interested in “Atom-related” comments at this point. For instance, you’ll notice “Delete” messages in the feed. We’ve talked about “Delete” or “Retract” capability often in the past and I’ve usually argued against it. However, it turns out to be necessary with this kind of feed since often earthquake reports are retracted as erroneous – often as the result of telemetry glitches. How should we best handle the need for “Delete” in this context? What will be easiest for clients to handle? ]]] If you consider the Atom entry stream as a set of idempotent synchronization messages, "delete" can be represented as an empty entry with the same id as a previous entry. (This is a very nice model to work with, in my experience: you have a set of inputs representing state, a set of inference rules, and an output state. Note that regardless of whether the entry stream represents a sampled state or discrete events, you want the loop to be closed at the consumer side, according to end-to-end principle.) Ziv Caspi   cell: +972-53-668-751     web: http://radio.weblogs.com/0106548/ From owner-atom-syntax@mail.imc.org Sat Jan 15 16:58: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 QAA06070 for ; Sat, 15 Jan 2005 16:58: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 j0FLognl043230; Sat, 15 Jan 2005 13: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 j0FLogrH043229; Sat, 15 Jan 2005 13:50:42 -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 j0FLofHE043210 for ; Sat, 15 Jan 2005 13:50:41 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 1so1208279rny for ; Sat, 15 Jan 2005 13: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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=hdMlMaLz6ubtMr3S3WHRrtDc9NmGKooeI4i8onMmtO8x04a/i3EyBloCO2iuAwFCyKZlWI82xmANxR6dmiltCVUDyhyvUQAqyKpj1qV9gCDdSkp1CdEmF7rMiksCQ9EwimtUjJBqcVDKu2Rn1wmLfT4ehqZmg/N4QpYwNsDgWQg= Received: by 10.38.179.48 with SMTP id b48mr508748rnf; Sat, 15 Jan 2005 13:50:36 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sat, 15 Jan 2005 13:50:36 -0800 (PST) Message-ID: <1f2ed5cd050115135062a9d81e@mail.gmail.com> Date: Sat, 15 Jan 2005 22:50:36 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Ziv Caspi Subject: Re: Please Review: Dissemination of Earthquake / Tsunami data via Atom Cc: bob@wyman.us, Atom Syntax In-Reply-To: <000001c4fb47$0b206a20$4542003e@zivchome> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 References: <200501102124.CHX73621@ms8.netsolmail.com> <000001c4fb47$0b206a20$4542003e@zivchome> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0FLogHE043224 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sat, 15 Jan 2005 23:12:57 +0200, Ziv Caspi wrote: > > Bob Wyman: > > [[[ > I am particularly interested in "Atom-related" comments at this point. For > instance, you'll notice "Delete" messages in the feed. We've talked about > "Delete" or "Retract" capability often in the past and I've usually argued > against it. However, it turns out to be necessary with this kind of feed > since often earthquake reports are retracted as erroneous – often as the > result of telemetry glitches. How should we best handle the need for > "Delete" in this context? What will be easiest for clients to handle? > ]]] > > If you consider the Atom entry stream as a set of idempotent synchronization > messages, "delete" can be represented as an empty entry with the same id as > a previous entry. (This is a very nice model to work with, in my experience: > you have a set of inputs representing state, a set of inference rules, and > an output state. Note that regardless of whether the entry stream represents > a sampled state or discrete events, you want the loop to be closed at the > consumer side, according to end-to-end principle.) To save a bit of searching: Empty content for deleted: http://www.imc.org/atom-syntax/mail-archive/msg11456.html Explicit http://www.imc.org/atom-syntax/mail-archive/msg08585.html Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Jan 15 17:10: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 RAA06645 for ; Sat, 15 Jan 2005 17:10: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 j0FM2Nj8044299; Sat, 15 Jan 2005 14:02: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 j0FM2NGT044298; Sat, 15 Jan 2005 14:02:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nic-naa.net (nic-naa.net [216.220.241.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0FM2MWv044290 for ; Sat, 15 Jan 2005 14:02:23 -0800 (PST) (envelope-from brunner@nic-naa.net) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.13.1/8.13.1) with ESMTP id j0FI0d1g032683; Sat, 15 Jan 2005 18:00:39 GMT (envelope-from brunner@nic-naa.net) Message-Id: <200501151800.j0FI0d1g032683@nic-naa.net> To: Ziv Caspi cc: bob@wyman.us, "'Atom Syntax'" , brunner@nic-naa.net Subject: Re: Please Review: Dissemination of Earthquake / Tsunami data via Atom In-Reply-To: Your message of "Sat, 15 Jan 2005 23:12:57 +0200." <000001c4fb47$0b206a20$4542003e@zivchome> Date: Sat, 15 Jan 2005 18:00:39 +0000 From: Eric Brunner-Williams in Portland Maine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: um... cancel messages? look, errors or state change repudiation is latent in all reported state. why "un-write" when you can "later-write"? From owner-atom-syntax@mail.imc.org Sun Jan 16 12:48: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 MAA00735 for ; Sun, 16 Jan 2005 12:48: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 j0G9cGqp023198; Sun, 16 Jan 2005 01: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 j0G9cG8R023197; Sun, 16 Jan 2005 01:38:16 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0G9cFZ8023160 for ; Sun, 16 Jan 2005 01:38:15 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta02-winn.mailhost.ntl.com ([212.250.162.8]) by mta05-winn.mailhost.ntl.com with ESMTP id <20050116093809.VZWF24912.mta05-winn.mailhost.ntl.com@aamta02-winn.mailhost.ntl.com>; Sun, 16 Jan 2005 09:38:09 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta02-winn.mailhost.ntl.com with ESMTP id <20050116093809.CUOW3760.aamta02-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Sun, 16 Jan 2005 09:38:09 +0000 Date: Sun, 16 Jan 2005 09:38:09 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <1821974922.20050116093809@djpowell.net> To: Graham CC: Atom Syntax Subject: Re: Feed, know thyself? In-Reply-To: <64EE2313-6737-11D9-8584-000A95DC3D90@mac.com> References: <1f2ed5cd0501141237701637f9@mail.gmail.com> <41E8312A.9040509@franklinmint.fm> <1f2ed5cd05011501051f29a0bc@mail.gmail.com> <41E96800.2080109@franklinmint.fm> <1943024938.20050115202848@djpowell.net> <64EE2313-6737-11D9-8584-000A95DC3D90@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 Saturday, January 15, 2005, 8:52:39 PM, you wrote: > On 15 Jan 2005, at 8:28 pm, David Powell wrote: >> 11.1 Verifying the Authenticity of Self Links > Can someone explain the attack model here? The worst that I can see > happening is that when you try to subscribe to my feed, you end up > subscribed to someone else's. How does this harm anyone but me? Feed id's are optional, so software is likely to use the feed location to identify feeds. So if a user subscribes to a feed with a faked "self" link, then they will see the initial entries of the faked document, merged with future entries from the real feed, which could be used to misrepresent the author of the real feed. It probably isn't a significant attack. If a user is vulnerable to subscribing to a fake feed, then redirecting the user to a genuine feed is the nicest thing the attacker could do. -- Dave From owner-atom-syntax@mail.imc.org Sun Jan 16 12:54: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 MAA01543 for ; Sun, 16 Jan 2005 12:54: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 j0GGQk66015565; Sun, 16 Jan 2005 08:26: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 j0GGQkmV015564; Sun, 16 Jan 2005 08:26:46 -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 j0GGQj5j015446 for ; Sun, 16 Jan 2005 08:26: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 j0GGPecZ028611; Sun, 16 Jan 2005 16:25:40 GMT In-Reply-To: <1821974922.20050116093809@djpowell.net> References: <1f2ed5cd0501141237701637f9@mail.gmail.com> <41E8312A.9040509@franklinmint.fm> <1f2ed5cd05011501051f29a0bc@mail.gmail.com> <41E96800.2080109@franklinmint.fm> <1943024938.20050115202848@djpowell.net> <64EE2313-6737-11D9-8584-000A95DC3D90@mac.com> <1821974922.20050116093809@djpowell.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-884005345; protocol="application/pkcs7-signature" Message-Id: <431670E4-67DB-11D9-BCDD-000A95DC3D90@mac.com> Cc: Atom Syntax From: Graham Subject: Re: Feed, know thyself? Date: Sun, 16 Jan 2005 16:25:40 +0000 To: David Powell X-Mailer: Apple Mail (2.619) 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-884005345 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 16 Jan 2005, at 9:38 am, David Powell wrote: > Feed id's are optional, so software is likely to use the feed location > to identify feeds. So if a user subscribes to a feed with a faked > "self" link, then they will see the initial entries of the faked > document, merged with future entries from the real feed, which could > be used to misrepresent the author of the real feed. The user would be trying to subscribe to my feed though, so it's equally likely they'll think I wrote the other person's entries. It's nothing you can't do with a HTTP redirect or a spoofed link. In any case I'd expect the aggregator to discard the content of the downloaded file and only use content downloaded from the "self" link. I don't know how other aggregators work, but in Shrook at least I'd have to make a deliberate effort to incorporate the contents of the file before switching to the linked feed. Graham --Apple-Mail-2-884005345 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 9w0BCQUxDxcNMDUwMTE2MTYyNTQwWjAjBgkqhkiG9w0BCQQxFgQUnIYwjbttlErSC07OhTMn71au yh0weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAJ0YEazNzIDdY8hW85XFm27hX 2hWqPN0Zd9oJWI2R7GRSVudE7r/7GnCYIReNk9i88cA0a4U3p0+bg38QXOydnZSpCZ8Co3o3h8Jj 2JdUrM3D9WzwIdivZZtHXg3WzsBk79ER4YZdrx0FNNC+lB8EreUFwW3JFk+CzYN36LdNEfp5xkzd wa7/BojL+sTMrl1+JfBJ9diIQzAyCppn9QcGyq1I/Fp1MGN3eqDbSrzVxzW2IXrcq+Z28lClHTsg o2OwHrLi2XqGpxfS1stzeW3mAFdtiSK9xwFbPkPOgoUVjY0Pr13CBn10UckekdK1QKYkbq+xwEnM L13etFZ1+sNH5gAAAAAAAA== --Apple-Mail-2-884005345-- From owner-atom-syntax@mail.imc.org Mon Jan 17 00:32: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 AAA18589 for ; Mon, 17 Jan 2005 00:32: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 j0H5FxxE032707; Sun, 16 Jan 2005 21:15: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 j0H5Fxbv032705; Sun, 16 Jan 2005 21:15:59 -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 j0H5Fw12032696 for ; Sun, 16 Jan 2005 21:15:58 -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 B00284F0DB; Mon, 17 Jan 2005 00:15:53 -0500 (EST) Message-Id: <6.0.0.20.2.20050117135912.074ec2f8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 17 Jan 2005 14:06:47 +0900 To: David Powell , Atom Syntax From: Martin Duerst Subject: Re: Posted PaceSimpleLanguageTagging In-Reply-To: <1863472781.20050115173047@djpowell.net> References: <1863472781.20050115173047@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 I think this proposal throws out the baby with the bathwater. I don't see any reason to introduce an atom:language element; xml:lang can serve exactly the same purpose. If you want to reduce the effect on performance/DBs, there are the following things that can be done: - Allow xml:lang only on some elements, but not on others. - Describe that inherited xml:lang does not apply to certain elements or attributes (e.g. things like dates, which are in a language-independent notation). Disallowing xml:lang on text constructs would be quite a bad idea in my view. As for RDF's support of xml:lang, there is a very RDF-specific, unfortunate issue that has to be taken into account when converting from atom to RDF/XML: RDF/XML at certain points cuts the inheritance of xml:lang. Regards, Martin. At 02:30 05/01/16, David Powell wrote: > > >PaceExtensionConstruct hopes to provide a basis for a mapping Atom to >models such as RDF [1], ER, and OO. I'm currently doing some work to see >whether there is anything in Atom that makes this unnecessarily >difficult. > >I think that Atom's use of xml:lang is likely to be a significant >problem to many implementors. I've posted PaceSimpleLanguageTagging >explaining the problem. > >http://www.intertwingly.net/wiki/pie/PaceSimpleLanguageTagging > > >[1] RDF supports language tagging of literals, so xml:lang doesn't > actually cause a serious problem for an Atom implementation based > on an RDF model. > >-- >Dave From owner-atom-syntax@mail.imc.org Mon Jan 17 01:15: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 BAA20571 for ; Mon, 17 Jan 2005 01:15: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 j0H68rmm001972; Sun, 16 Jan 2005 22: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 j0H68rJI001971; Sun, 16 Jan 2005 22:08: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.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0H68pTd001878 for ; Sun, 16 Jan 2005 22:08:52 -0800 (PST) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so242088wra for ; Sun, 16 Jan 2005 22:08: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:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=p2PMry5B3QEK7RN8n3no8gA9tHtSLNqwtCnR88m2N21h6aUvMYLxOw6917PI/r9XmeTiouR3KwTK+oNPgln8zK+GBegEqDszlnjZ63efMA/17uiRfViOvBUrHGahOrg2t3ToLaCouo9k0Hi8XK8T9ug4rGywhbWQAckZgwJPSR0= Received: by 10.54.41.37 with SMTP id o37mr159458wro; Sun, 16 Jan 2005 22:08:44 -0800 (PST) Received: by 10.54.18.2 with HTTP; Sun, 16 Jan 2005 22:08:44 -0800 (PST) Message-ID: <540e3732050116220832105c35@mail.gmail.com> Date: Mon, 17 Jan 2005 00:08:44 -0600 From: "Roger B." Reply-To: "Roger B." To: Danny Ayers Subject: Re: Feed, know thyself? Cc: atom-syntax@imc.org In-Reply-To: <1f2ed5cd0501141237701637f9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd0501141237701637f9@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny: Works for me, at least in the sense that I have no problem with it while wearing either of my blogging or aggregating hats. I would like to see some of the objections fleshed out a bit, though, just in case we're overlooking something significant. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Mon Jan 17 01:50: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 BAA22702 for ; Mon, 17 Jan 2005 01:50: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 j0H6dfgO018972; Sun, 16 Jan 2005 22:39: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 j0H6dfY7018971; Sun, 16 Jan 2005 22:39: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 j0H6dece018946 for ; Sun, 16 Jan 2005 22:39: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 j0H6dcVu001343 for ; Sun, 16 Jan 2005 23:39:38 -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 <0IAG001CQ7U1GA@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 16 Jan 2005 23:39:38 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAG000RT7U17R@mail.sun.net> for atom-syntax@imc.org; Sun, 16 Jan 2005 23:39:37 -0700 (MST) Date: Sun, 16 Jan 2005 22:39:49 -0800 From: Tim Bray Subject: Re: Posted PaceSimpleLanguageTagging In-reply-to: <1863472781.20050115173047@djpowell.net> To: David Powell Cc: Atom Syntax Message-id: <95C3A462-6852-11D9-B581-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: <1863472781.20050115173047@djpowell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 15, 2005, at 9:30 AM, David Powell wrote: > PaceExtensionConstruct hopes to provide a basis for a mapping Atom to > models such as RDF [1], ER, and OO. I'm currently doing some work to > see > whether there is anything in Atom that makes this unnecessarily > difficult. > > I think that Atom's use of xml:lang is likely to be a significant > problem to many implementors. I've posted PaceSimpleLanguageTagging > explaining the problem. I'm fairly unconvinced that this is will loom very large in the universe of implementor problems. If it turns out that it's really an issue, couldn't you achieve the desired effect by restricting xml:lang to appear only on atom:entry and atom:feed? I have to admit that I'm having trouble imagining a scenario where you'd want to scatter xml:lang's randomly around an atom instance, so maybe this is a handy simplification. Obviously, all bets are off once you get inside atom:content, right? -Tim From owner-atom-syntax@mail.imc.org Mon Jan 17 04:03: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 EAA18390 for ; Mon, 17 Jan 2005 04: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 j0H8lohW080802; Mon, 17 Jan 2005 00:47: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 j0H8lokI080801; Mon, 17 Jan 2005 00:47:50 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0H8lnjK080682 for ; Mon, 17 Jan 2005 00:47:50 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta08-winn.mailhost.ntl.com ([212.250.162.8]) by mta05-winn.mailhost.ntl.com with ESMTP id <20050117084733.OOGS24912.mta05-winn.mailhost.ntl.com@aamta08-winn.mailhost.ntl.com>; Mon, 17 Jan 2005 08:47:33 +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 <20050117084733.KSFP7419.aamta08-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Mon, 17 Jan 2005 08:47:33 +0000 Date: Mon, 17 Jan 2005 08:47:31 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <1357402830.20050117084731@djpowell.net> To: Tim Bray CC: David Powell , Atom Syntax Subject: Re: Posted PaceSimpleLanguageTagging In-Reply-To: <95C3A462-6852-11D9-B581-000A95A51C9E@sun.com> References: <1863472781.20050115173047@djpowell.net> <95C3A462-6852-11D9-B581-000A95A51C9E@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 Monday, January 17, 2005, 6:39:49 AM, you wrote: > On Jan 15, 2005, at 9:30 AM, David Powell wrote: >> PaceExtensionConstruct hopes to provide a basis for a mapping Atom to >> models such as RDF [1], ER, and OO. I'm currently doing some work to >> see >> whether there is anything in Atom that makes this unnecessarily >> difficult. >> >> I think that Atom's use of xml:lang is likely to be a significant >> problem to many implementors. I've posted PaceSimpleLanguageTagging >> explaining the problem. > I'm fairly unconvinced that this is will loom very large in the > universe of implementor problems. For an atom implementation where content is entered via HTML forms, or from an existing CMS - then this isn't a problem. The user won't be able to scatter xml:lang's everywhere. But for an implementation based on Atom Protocol, the server needs to preserve all of this stuff. > If it turns out that it's really an > issue, couldn't you achieve the desired effect by restricting xml:lang > to appear only on atom:entry and atom:feed? See my reply to Martin. Restricting the position of xml:lang could make things worse, unless we also restrict its inheritance - which I'm not sure that we are allowed to do. What do you think about only allowing it on atom:content and on Text constructs? > I have to admit that I'm having trouble imagining a scenario where > you'd want to scatter xml:lang's randomly around an atom instance, so > maybe this is a handy simplification. I think that if we allow xml:lang then it should definitely be restricted. The current "xml:lang everywhere" situation is only simple to implement if you assume that your implementation stores all of it's data in an XML DOM. > Obviously, all bets are off once you get inside atom:content, right? Well, HTML and XHTML can include lang, and xml:lang according to their specs. They inherit the default language from their envelope. I think that is pretty well defined. -- Dave From owner-atom-syntax@mail.imc.org Mon Jan 17 04:04: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 EAA18411 for ; Mon, 17 Jan 2005 04:04: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 j0H8lpCo080808; Mon, 17 Jan 2005 00:47: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 j0H8lpsW080807; Mon, 17 Jan 2005 00:47:51 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0H8lnmN080677 for ; Mon, 17 Jan 2005 00:47:50 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta05-winn.mailhost.ntl.com ([212.250.162.8]) by mta10-winn.mailhost.ntl.com with ESMTP id <20050117084733.PGPE15581.mta10-winn.mailhost.ntl.com@aamta05-winn.mailhost.ntl.com>; Mon, 17 Jan 2005 08:47:33 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta05-winn.mailhost.ntl.com with ESMTP id <20050117084733.HSNW769.aamta05-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Mon, 17 Jan 2005 08:47:33 +0000 Date: Mon, 17 Jan 2005 08:47:30 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <1316945519.20050117084730@djpowell.net> To: Martin Duerst CC: David Powell , Atom Syntax Subject: Re: Posted PaceSimpleLanguageTagging In-Reply-To: <6.0.0.20.2.20050117135912.074ec2f8@localhost> References: <1863472781.20050115173047@djpowell.net> <6.0.0.20.2.20050117135912.074ec2f8@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0H8lomN080792 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Monday, January 17, 2005, 5:06:47 AM, you wrote: > I think this proposal throws out the baby with the bathwater. > I don't see any reason to introduce an atom:language element; > xml:lang can serve exactly the same purpose. If you want to > reduce the effect on performance/DBs, there are the following > things that can be done: > - Allow xml:lang only on some elements, but not on others. > - Describe that inherited xml:lang does not apply to certain > elements or attributes (e.g. things like dates, which are > in a language-independent notation). Reading the XML spec, I'm not clear that we're allowed to restrict the inheritance of xml:lang? From the spec: > The intent declared with xml:lang is considered to apply to all > attributes and content of the element where it is specified, unless > overridden with an instance of xml:lang on another element within > that content. > Disallowing xml:lang on text constructs would be quite a bad > idea in my view. I'm fine with allowing it on Text constructs. My worry is allowing to inherit to elements where it is not appropriate (such as atom:generator, and extension elements.) If we allow it to inherit inappropriately, and we restrict it to certain elements, then this makes the situation even worse, as we'll have no way of re-declaring or un-declaring xml:lang on elements that it shouldn't apply to. I think it is very unlikely that a user would want to include a title, summary, and content in a different language. I agree that content might include more than one language, but that is already catered for by XHTML/HTML's use of xml:lang/lang. If we only allow xml:lang on Text constructs and atom:content, then this means that the user would typically have to include it on titles, summaries, and content separately. Would that be ok? Would it be any better than a dc:language style atom:language? > As for RDF's support of xml:lang, there is a very RDF-specific, > unfortunate issue that has to be taken into account when > converting from atom to RDF/XML: RDF/XML at certain points > cuts the inheritance of xml:lang. I didn't realize this - where is it? -- Dave From owner-atom-syntax@mail.imc.org Mon Jan 17 10:26: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 KAA14526 for ; Mon, 17 Jan 2005 10:26: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 j0HFD5ck027692; Mon, 17 Jan 2005 07:13: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 j0HFD5c8027691; Mon, 17 Jan 2005 07:13: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 j0HFD4BT027677 for ; Mon, 17 Jan 2005 07:13:05 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 83019 invoked by uid 17064); 17 Jan 2005 15:12:55 -0000 Received: from unknown (HELO [192.168.0.7]) ([193.253.244.202]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 17 Jan 2005 15:12:55 -0000 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <44B27E00-689A-11D9-993A-000A95D9FA7A@bblfish.net> Content-Type: text/plain; charset=US-ASCII; format=flowed To: "'Atom WG'" From: Henry Story Subject: AtomOWL & AtomIsRDF Date: Mon, 17 Jan 2005 16:12:57 +0100 X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I have put up two pages (Paces) on the wiki. One AtomOWL [1] just is a place to work on the latest RDF model of Atom, and fulfill the requirement that Atom have a model. The Other AtomIsRDF [2] is a place to track the way for Atom to fulfill its extensibility requirements, by closing the gap with RDF. As you will see there is not a lot of difference really. So this should harm no one, but make it much easier to extend atom in a failsafe way. Henry Story [1] http://www.intertwingly.net/wiki/pie/AtomOWL [2] http://www.intertwingly.net/wiki/pie/AtomIsRDF From owner-atom-syntax@mail.imc.org Mon Jan 17 12: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 MAA26602 for ; Mon, 17 Jan 2005 12: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 j0HHGbUt049421; Mon, 17 Jan 2005 09:16: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 j0HHGbQu049420; Mon, 17 Jan 2005 09:16:37 -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 j0HHGbcl049413 for ; Mon, 17 Jan 2005 09:16:37 -0800 (PST) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id A7D344F22B; Mon, 17 Jan 2005 12:16:36 -0500 (EST) Date: Mon, 17 Jan 2005 12:16:36 -0500 From: Dan Brickley To: Henry Story Cc: "'Atom WG'" Subject: Re: AtomOWL & AtomIsRDF Message-ID: <20050117171636.GK28196@homer.w3.org> References: <44B27E00-689A-11D9-993A-000A95D9FA7A@bblfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44B27E00-689A-11D9-993A-000A95D9FA7A@bblfish.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: * Henry Story [2005-01-17 16:12+0100] > > I have put up two pages (Paces) on the wiki. > > One AtomOWL [1] just is a place to work on the latest RDF model of > Atom, and fulfill > the requirement that Atom have a model. > > The Other AtomIsRDF [2] is a place to track the way for Atom to fulfill > its extensibility requirements, by closing the gap with RDF. As you > will see there > is not a lot of difference really. So this should harm no one, but make > it much easier to extend atom in a failsafe way. I fear [2] is unfortunately named. Atom is RDF-like in some ways, but until the Atom spec says "Atom is RDF", Atom isn't RDF. A surface similarity to RDF's XML encoding, or even to RDF's graph data model, isn't by itself enough to declare that Atom "is" RDF. For example, there have been threads here about defaulting, about data being implied if missing, and other things that have no clear RDF equivalent. The name "Atom is RDF" goes somewhat against the decision record of this group, which has been pretty clear in its non-RDFness. Wiki style tends towards the consensual, so I suggest renaming it to AtomRDF or similar. Even as an RDF enthusiast, I find the name problematic. So I'm concerned that "Atom is RDF" will annoy people needlessly, which would be a shame since the work you've been doing on an RDF/OWL view of the Atom format is both interesting and valuable. Dan > Henry Story > > [1] http://www.intertwingly.net/wiki/pie/AtomOWL > [2] http://www.intertwingly.net/wiki/pie/AtomIsRDF From owner-atom-syntax@mail.imc.org Mon Jan 17 12:48: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 MAA28329 for ; Mon, 17 Jan 2005 12:48: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 j0HHc8jr052256; Mon, 17 Jan 2005 09:38: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 j0HHc80D052255; Mon, 17 Jan 2005 09:38:08 -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 j0HHc80h052248 for ; Mon, 17 Jan 2005 09:38:08 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 7651 invoked by uid 17064); 17 Jan 2005 17:38:08 -0000 Received: from unknown (HELO [192.168.0.7]) ([193.253.244.61]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 17 Jan 2005 17:38:08 -0000 In-Reply-To: <20050117171636.GK28196@homer.w3.org> References: <44B27E00-689A-11D9-993A-000A95D9FA7A@bblfish.net> <20050117171636.GK28196@homer.w3.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8D14E560-68AE-11D9-993A-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: "'Atom WG'" From: Henry Story Subject: Re: AtomOWL & AtomIsRDF Date: Mon, 17 Jan 2005 18:38:08 +0100 To: Dan Brickley X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 17 Jan 2005, at 18:16, Dan Brickley wrote: > [snip] > I fear [2] is unfortunately named. Atom is RDF-like in some ways, > but until the Atom spec says "Atom is RDF", Atom isn't RDF. A surface > similarity to RDF's XML encoding, or even to RDF's graph data model, > isn't by itself enough to declare that Atom "is" RDF. For example, > there > have been threads here about defaulting, about data being implied if > missing, and other things that have no clear RDF equivalent. The name > "Atom is RDF" goes somewhat against the decision record of this group, > which has been pretty clear in its non-RDFness. Wiki style tends > towards > the consensual, so I suggest renaming it to AtomRDF or similar. Yes, very good point. I have created a new Page called AtomRDF [3], whose aim is to track what would be needed for an Atom document to be an RDF document. It is only if we are clear about these that it will be possible to come to a reasoned decision on the value of perhaps bridging the gap. The gap is I think a lot smaller than most people think (which is what I was trying to emphasize with the AtomIsRDF name) But you are right, there still is one. > Even as an RDF enthusiast, I find the name problematic. So I'm > concerned > that "Atom is RDF" will annoy people needlessly, which would be a shame > since the work you've been doing on an RDF/OWL view of the Atom format > is both interesting and valuable. > > Dan > >> Henry Story >> >> [1] http://www.intertwingly.net/wiki/pie/AtomOWL >> [2] http://www.intertwingly.net/wiki/pie/AtomIsRDF [3] http://www.intertwingly.net/wiki/pie/AtomIsRDF From owner-atom-syntax@mail.imc.org Mon Jan 17 13:23: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 NAA01689 for ; Mon, 17 Jan 2005 13:23: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 j0HIBDV0059348; Mon, 17 Jan 2005 10:11: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 j0HIBD05059346; Mon, 17 Jan 2005 10:11:13 -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 j0HIBCOd059338 for ; Mon, 17 Jan 2005 10:11:12 -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 j0HIBBdt011650 for ; Mon, 17 Jan 2005 11:11:12 -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 <0IAH001LO3UNGA@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 17 Jan 2005 11:11:11 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAH005B33UMUK@mail.sun.net> for atom-syntax@imc.org; Mon, 17 Jan 2005 11:11:11 -0700 (MST) Date: Mon, 17 Jan 2005 10:11:22 -0800 From: Tim Bray Subject: Re: Posted PaceSimpleLanguageTagging In-reply-to: <1357402830.20050117084731@djpowell.net> To: David Powell Cc: Atom Syntax Message-id: <31C9992B-68B3-11D9-A757-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: <1863472781.20050115173047@djpowell.net> <95C3A462-6852-11D9-B581-000A95A51C9E@sun.com> <1357402830.20050117084731@djpowell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 17, 2005, at 12:47 AM, David Powell wrote: >> If it turns out that it's really an >> issue, couldn't you achieve the desired effect by restricting xml:lang >> to appear only on atom:entry and atom:feed? > > See my reply to Martin. Restricting the position of xml:lang could > make things worse, unless we also restrict its inheritance - which I'm > not sure that we are allowed to do. > > What do you think about only allowing it on atom:content and on Text > constructs? I'm very concerned. Any time you're processing text and you want to display it or index it for search, or do pretty well anything, if you don't know what language it's in you're probably going to make damaging mistakes. Consider a Turkish author whose name begins with 'I'... feed that to a search engine that doesn't know it's in Turkish and the results will be wrong. Suppose Joi Ito wants to list his name in Japanese but still write in English; or the the reverse. Suppose I'm publishing in Moscow and I want my copyright statement to be in Russian irrespective of what language I'm writing in? > I think that if we allow xml:lang then it should definitely be > restricted. The current "xml:lang everywhere" situation is only simple > to implement if you assume that your implementation stores all of it's > data in an XML DOM. This statement is not correct; it's simple to implement correctly if you're doing stream processing. And I repeat, anything that is remotely general-purpose needs to associate each little chunk of text with its language, if it wants to operate correctly. Sometimes being correct has convenience costs. I'm veering towards -1 on this one, absent a few more people putting up their hands to say "we must have it". -Tim From owner-atom-syntax@mail.imc.org Mon Jan 17 13:47: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 NAA03493 for ; Mon, 17 Jan 2005 13:47: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 j0HIa1VH062199; Mon, 17 Jan 2005 10:36: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 j0HIa1FL062198; Mon, 17 Jan 2005 10:36:01 -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 j0HIa0WS062168 for ; Mon, 17 Jan 2005 10:36:00 -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 A888FE4; Mon, 17 Jan 2005 10:35:53 -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 j0HIZlKB012190; Mon, 17 Jan 2005 10:35:48 -0800 (PST) Date: Mon, 17 Jan 2005 10:52:36 -0800 From: Walter Underwood To: Dan Brickley , Henry Story Cc: "'Atom WG'" Subject: Re: AtomOWL & AtomIsRDF Message-ID: <2AC9C1B91489803AF6A1F4D9@diva.verity.com> In-Reply-To: <20050117171636.GK28196@homer.w3.org> References: <44B27E00-689A-11D9-993A-000A95D9FA7A@bblfish.net> <20050117171636.GK28196@homer.w3.org> 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 Monday, January 17, 2005 12:16:36 PM -0500 Dan Brickley wrote: > > I fear [2] is unfortunately named. Atom is RDF-like in some ways, > but until the Atom spec says "Atom is RDF", Atom isn't RDF. Call it "AtomAsRDF". wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Mon Jan 17 14:06: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 OAA04507 for ; Mon, 17 Jan 2005 14:06: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 j0HIxUPw076589; Mon, 17 Jan 2005 10: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 j0HIxUAA076588; Mon, 17 Jan 2005 10:59: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 j0HIxTa0076497 for ; Mon, 17 Jan 2005 10:59:29 -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 1Cqc5F-00007D-5C; Mon, 17 Jan 2005 18:58:37 +0000 Message-ID: <41EC0B08.20605@franklinmint.fm> Date: Mon, 17 Jan 2005 13:59:20 -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: David Powell , Atom Syntax Subject: Re: Posted PaceSimpleLanguageTagging References: <1863472781.20050115173047@djpowell.net> <95C3A462-6852-11D9-B581-000A95A51C9E@sun.com> <1357402830.20050117084731@djpowell.net> <31C9992B-68B3-11D9-A757-000A95A51C9E@sun.com> In-Reply-To: <31C9992B-68B3-11D9-A757-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 Jan 17, 2005, at 12:47 AM, David Powell wrote: > > >> I think that if we allow xml:lang then it should definitely be >> restricted. The current "xml:lang everywhere" situation is only simple >> to implement if you assume that your implementation stores all of it's >> data in an XML DOM. > > This statement is not correct; it's simple to implement correctly if > you're doing stream processing. > I think David's issue with xml:lang concerns mapping Atom entries to, say, an RDBMS. I think he feels it will be challenging to store with that requirement. For instance, what does it mean to include an xml:lang declaration on atom:updated? Robert Sayre From owner-atom-syntax@mail.imc.org Mon Jan 17 14:15: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 OAA05113 for ; Mon, 17 Jan 2005 14:15: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 j0HJ6Xal082862; Mon, 17 Jan 2005 11: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 j0HJ6XcR082860; Mon, 17 Jan 2005 11:06: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 j0HJ6WRt082840 for ; Mon, 17 Jan 2005 11:06:32 -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 j0HJ6Wdt005383 for ; Mon, 17 Jan 2005 12:06:32 -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 <0IAH001VC6EVGA@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 17 Jan 2005 12:06:31 -0700 (MST) Received: from [192.168.1.30] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAH000DN6EU7R@mail.sun.net> for atom-syntax@imc.org; Mon, 17 Jan 2005 12:06:31 -0700 (MST) Date: Mon, 17 Jan 2005 11:06:42 -0800 From: Tim Bray Subject: Re: Posted PaceSimpleLanguageTagging In-reply-to: <41EC0B08.20605@franklinmint.fm> To: Robert Sayre Cc: Atom Syntax , David Powell 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: <1863472781.20050115173047@djpowell.net> <95C3A462-6852-11D9-B581-000A95A51C9E@sun.com> <1357402830.20050117084731@djpowell.net> <31C9992B-68B3-11D9-A757-000A95A51C9E@sun.com> <41EC0B08.20605@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 17, 2005, at 10:59 AM, Robert Sayre wrote: > I think David's issue with xml:lang concerns mapping Atom entries to, > say, an RDBMS. I think he feels it will be challenging to store with > that requirement. For instance, what does it mean to include an > xml:lang declaration on atom:updated? Clearly, it means nothing, and such an occurrence can safely be ignored or discarded. What am I missing? -Tim From owner-atom-syntax@mail.imc.org Mon Jan 17 14:27: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 OAA05822 for ; Mon, 17 Jan 2005 14:27: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 j0HJHKqR088993; Mon, 17 Jan 2005 11:17: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 j0HJHKNT088992; Mon, 17 Jan 2005 11:17:20 -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 j0HJHJUN088986 for ; Mon, 17 Jan 2005 11:17:19 -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 1CqcMa-0000HR-SX; Mon, 17 Jan 2005 19:16:32 +0000 Message-ID: <41EC0F3C.3010001@franklinmint.fm> Date: Mon, 17 Jan 2005 14:17:16 -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 , David Powell Subject: Re: Posted PaceSimpleLanguageTagging References: <1863472781.20050115173047@djpowell.net> <95C3A462-6852-11D9-B581-000A95A51C9E@sun.com> <1357402830.20050117084731@djpowell.net> <31C9992B-68B3-11D9-A757-000A95A51C9E@sun.com> <41EC0B08.20605@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 Jan 17, 2005, at 10:59 AM, Robert Sayre wrote: > >> I think David's issue with xml:lang concerns mapping Atom entries to, >> say, an RDBMS. I think he feels it will be challenging to store with >> that requirement. For instance, what does it mean to include an >> xml:lang declaration on atom:updated? > > > Clearly, it means nothing, and such an occurrence can safely be ignored > or discarded. What am I missing? -Tim > Let's say I use an Atom protocol client to PUT an entry that has an xml:lang attribute. Is it ok for the server to respond with a 204 if drops the xml:lang declaration? After all, that's exactly not what I PUT there. I think David is asking for the spec to declare when xml:lang can be "safely ignored and discarded". Put another way, where is it part of the Atom model. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Jan 17 14:43: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 OAA06896 for ; Mon, 17 Jan 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 j0HJbGaI098906; Mon, 17 Jan 2005 11:37: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 j0HJbG1m098905; Mon, 17 Jan 2005 11:37: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 j0HJbFUj098887 for ; Mon, 17 Jan 2005 11:37: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 j0HJbFVu001417 for ; Mon, 17 Jan 2005 12:37:15 -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 <0IAH001QO7U2GA@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 17 Jan 2005 12:37:15 -0700 (MST) Received: from [192.168.1.30] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAH000HQ7U27R@mail.sun.net> for atom-syntax@imc.org; Mon, 17 Jan 2005 12:37:14 -0700 (MST) Date: Mon, 17 Jan 2005 11:37:26 -0800 From: Tim Bray Subject: Re: Posted PaceSimpleLanguageTagging In-reply-to: <41EC0F3C.3010001@franklinmint.fm> To: Robert Sayre Cc: Atom Syntax , David Powell Message-id: <378CBA16-68BF-11D9-A757-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: <1863472781.20050115173047@djpowell.net> <95C3A462-6852-11D9-B581-000A95A51C9E@sun.com> <1357402830.20050117084731@djpowell.net> <31C9992B-68B3-11D9-A757-000A95A51C9E@sun.com> <41EC0B08.20605@franklinmint.fm> <41EC0F3C.3010001@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 17, 2005, at 11:17 AM, Robert Sayre wrote: >>> For instance, what does it mean to include an xml:lang declaration >>> on atom:updated? >> Clearly, it means nothing, and such an occurrence can safely be >> ignored or discarded. What am I missing? -Tim > > Let's say I use an Atom protocol client to PUT an entry that has an > xml:lang attribute. Is it ok for the server to respond with a 204 if > drops the xml:lang declaration? After all, that's exactly not what I > PUT there. The semantics of xml:lang (http://www.w3.org/TR/REC-xml/#sec-lang-tag) are very clear. Given the definition of atom:updated, it is unambiguously true that such an attribute can have no effect. I would drop it and return 204 without a moment's worry. > I think David is asking for the spec to declare when xml:lang can be > "safely ignored and discarded". Put another way, where is it part of > the Atom model. Draft format-04 says "Requirements regarding the content and interpretation of xml:lang are specified in XML 1.0 [W3C.REC-xml-20040204] Section 2.12." If the element or attribute so labeled contains free text, xml:lang is relevant. If not, not. If you don't know (i.e. on some other-namespace exception), you'd better preserve it. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 17 14:45: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 OAA06994 for ; Mon, 17 Jan 2005 14:45: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 j0HJcTRC099269; Mon, 17 Jan 2005 11:38: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 j0HJcTov099268; Mon, 17 Jan 2005 11:38:29 -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 j0HJcSRP099242 for ; Mon, 17 Jan 2005 11:38:28 -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 j0HJcJKj001330; Mon, 17 Jan 2005 14:38:19 -0500 (EST) Message-ID: <41EC1429.2060503@intertwingly.net> Date: Mon, 17 Jan 2005 14:38:17 -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 WG'" Subject: Re: AtomOWL & AtomIsRDF References: <44B27E00-689A-11D9-993A-000A95D9FA7A@bblfish.net> <20050117171636.GK28196@homer.w3.org> <8D14E560-68AE-11D9-993A-000A95D9FA7A@bblfish.net> In-Reply-To: <8D14E560-68AE-11D9-993A-000A95D9FA7A@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: > > Yes, very good point. I have created a new Page called AtomRDF [3], > whose aim > is to track what would be needed for an Atom document to be an RDF > document. I have a number of problems with the AtomRDF document as it stands now. For starters, the current atom:generator element has optional "uri" and "version" elements, not "atom:uri" and "atom:version" elements. Unfortunately, these are quite different. More siginificantly, the document does not address the largest issue, which is content. I do believe that it would be possible, and perhaps quite useful, to define an XSLT tranform from Atom/XML to RDF/XML. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Jan 17 14:48: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 OAA07150 for ; Mon, 17 Jan 2005 14:48: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 j0HJXgC8098144; Mon, 17 Jan 2005 11:33: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 j0HJXg0D098143; Mon, 17 Jan 2005 11:33:42 -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 j0HJXfuH098094 for ; Mon, 17 Jan 2005 11:33: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 j0HJXWG6008203; Mon, 17 Jan 2005 14:33:33 -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 CJH90801 (AUTH bob@wyman.us); Mon, 17 Jan 2005 14:33:31 -0500 (EST) Message-Id: <200501171933.CJH90801@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'David Powell'" , "'Atom Syntax'" Subject: RE: Posted PaceSimpleLanguageTagging Date: Mon, 17 Jan 2005 14:32:48 -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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcT7KnJqgi74THx4SEqEVliEFMELGQBn+fhA In-Reply-To: <1863472781.20050115173047@djpowell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Powell wrote: > I think that Atom's use of xml:lang is likely to be a significant > problem to many implementors. Life is tough! So what? XML gives us a standard way to flag the language of things. Unless there is a really compelling argument to do something different, it isn't appropriate for us to diverge from the standard. If a compelling argument *can* be found, then we probably should be talking about revising the base XML specifications. We've spent decades working on providing the mechanisms so that we can handle non-English data properly. Let's not go backwards with Atom. RSS already made the mistake of including a "language" tag and it is a mess that others are copying into other formats. Let's not contribute to this pollution of the schema-space.... There are some fields in Atom which are "language-independent" or "neutral" and thus it might be useful to explicitly prevent the use of xml:lang tags for these elements or simply state that they have no meaning if used. For instance, atom:id, atom:modified, atom:updated, have semantics and syntax which is independent of language. However, all other fields should be candidates for xml:lang. bob wyman From owner-atom-syntax@mail.imc.org Mon Jan 17 14:53: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 OAA07537 for ; Mon, 17 Jan 2005 14:53: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 j0HJjuB2003828; Mon, 17 Jan 2005 11:45: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 j0HJjuVU003827; Mon, 17 Jan 2005 11:45:56 -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 j0HJjtMr003790 for ; Mon, 17 Jan 2005 11:45:55 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 94612 messnum 2011627 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 17 Jan 2005 19:45:49 -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 94612) with SMTP; 17 Jan 2005 19:45:49 -0000 Message-ID: <41EC15EA.7030305@dehora.net> Date: Mon, 17 Jan 2005 19:45:46 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: Posted PaceSimpleLanguageTagging References: <1863472781.20050115173047@djpowell.net> <95C3A462-6852-11D9-B581-000A95A51C9E@sun.com> <1357402830.20050117084731@djpowell.net> <31C9992B-68B3-11D9-A757-000A95A51C9E@sun.com> <41EC0B08.20605@franklinmint.fm> 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 Tim Bray wrote: > > On Jan 17, 2005, at 10:59 AM, Robert Sayre wrote: > >> I think David's issue with xml:lang concerns mapping Atom entries to, >> say, an RDBMS. I think he feels it will be challenging to store with >> that requirement. For instance, what does it mean to include an >> xml:lang declaration on atom:updated? > > Clearly, it means nothing, and such an occurrence can safely be ignored > or discarded. What am I missing? -Tim I'm not too fussed about the outcome either way, but one problem seems to be this - when it means nothing isn't specified. [I'm not sure we should spend a lot of time coping with fact that xml:lang isn't a universally applicable attribute for syndication markup.] cheers Bill From owner-atom-syntax@mail.imc.org Mon Jan 17 15:06: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 PAA09175 for ; Mon, 17 Jan 2005 15:06: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 j0HJstjn009757; Mon, 17 Jan 2005 11:54: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 j0HJstcS009756; Mon, 17 Jan 2005 11:54:55 -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 j0HJssx2009568 for ; Mon, 17 Jan 2005 11:54:54 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 34so802154rns for ; Mon, 17 Jan 2005 11:54: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:mime-version:content-type:content-transfer-encoding; b=XU0nXw3weGw9mO9L58E0zYqcpJEf6vWOkogqEo1ZLtqMkaM4DLHAJJtWproeitONjq8sSn4oSNxb8Rts4tUg6AR9YKRCAV8sBWFqrdG6zMRGXPvzlJnPnYtkOxqH+zyshETenGK977+53jG0gLiMNTzGXHQO+M4YHUjPCw1ruX0= Received: by 10.38.179.46 with SMTP id b46mr268447rnf; Mon, 17 Jan 2005 11:54:48 -0800 (PST) Received: by 10.38.179.71 with HTTP; Mon, 17 Jan 2005 11:54:48 -0800 (PST) Message-ID: <1f2ed5cd050117115414c91b@mail.gmail.com> Date: Mon, 17 Jan 2005 20:54:48 +0100 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: Content datatypes in XSD? 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 It's been a long time since I looked at XML schemas, but would be possible to express the content type attribute at all neatly using a complex type? I imagine the "TEXT" | "HTML" | "XHTML" part would be straightforward, but doesn't the | "pretty/much;anything" option screw things up? Cheers, Danny. 5.12.1 "type" attribute atom:content MAY have a "type" attribute, When present, the value MAY be one of "TEXT", "HTML", or "XHTML". Failing that, it MUST be a MIME media type [RFC2045] in which, to use the terminology of Section 5 of [RFC2045], the top level is a discrete type. If the type attribute is not provided, software MUST behave as though it were present with a value of "TEXT". -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Mon Jan 17 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 PAA11213 for ; Mon, 17 Jan 2005 15:24: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 j0HKG7DK024420; Mon, 17 Jan 2005 12:16: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 j0HKG7RW024419; Mon, 17 Jan 2005 12:16:07 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0HKG6KQ024222 for ; Mon, 17 Jan 2005 12:16:06 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta08-winn.mailhost.ntl.com ([212.250.162.8]) by mta10-winn.mailhost.ntl.com with ESMTP id <20050117201600.UKXJ15581.mta10-winn.mailhost.ntl.com@aamta08-winn.mailhost.ntl.com>; Mon, 17 Jan 2005 20:16:00 +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 <20050117201600.KKWQ7419.aamta08-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Mon, 17 Jan 2005 20:16:00 +0000 Date: Mon, 17 Jan 2005 20:15:54 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <644242235.20050117201554@djpowell.net> To: Tim Bray CC: Atom Syntax Subject: Re: Posted PaceSimpleLanguageTagging In-Reply-To: <31C9992B-68B3-11D9-A757-000A95A51C9E@sun.com> References: <1863472781.20050115173047@djpowell.net> <95C3A462-6852-11D9-B581-000A95A51C9E@sun.com> <1357402830.20050117084731@djpowell.net> <31C9992B-68B3-11D9-A757-000A95A51C9E@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 Monday, January 17, 2005, 6:11:22 PM, you wrote: >> What do you think about only allowing it on atom:content and on Text >> constructs? > I'm very concerned. Any time you're processing text and you want to > display it or index it for search, or do pretty well anything, if you > don't know what language it's in you're probably going to make damaging > mistakes. Consider a Turkish author whose name begins with 'I'... feed > that to a search engine that doesn't know it's in Turkish and the > results will be wrong. Yes this does sound like a problem. > Suppose Joi Ito wants to list his name in > Japanese but still write in English; or the the reverse. Let's hope he doesn't want to provide a name in more than one language. > Suppose I'm > publishing in Moscow and I want my copyright statement to be in Russian > irrespective of what language I'm writing in? Copyright is a Text Construct, so at least this one would be ok. >> I think that if we allow xml:lang then it should definitely be >> restricted. The current "xml:lang everywhere" situation is only simple >> to implement if you assume that your implementation stores all of it's >> data in an XML DOM. > This statement is not correct; it's simple to implement correctly if > you're doing stream processing. I agree, parsing is simple whether it is stream or tree parsing. I'm worried about what we do with this data afterwards. It isn't clear what xml:lang should apply to? Does it apply to email addresses? Aural browsers might use it as a pronunciation hint. So does a database implementation need an "email_lang" column in the table or not? I think we need to decide on these issues rather than leave it to implementors to guess. > And I repeat, anything that is remotely general-purpose needs to > associate each little chunk of text with its language, if it wants to > operate correctly. Sometimes being correct has convenience costs. I'm not suggesting that "xml:lang everywhere" is useless. I'm pointing out that the costs are deceptively high. If the consensus is that the current situation is acceptable then I'll be ok with that. My Pace might not be an acceptable solution, but I think we perhaps ought to be clear about what xml:lang applies to, including a strategy for extensions. -- Dave From owner-atom-syntax@mail.imc.org Mon Jan 17 15:25: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 PAA11424 for ; Mon, 17 Jan 2005 15:25: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 j0HKFYIH023967; Mon, 17 Jan 2005 12:15: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 j0HKFYb4023966; Mon, 17 Jan 2005 12:15: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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0HKFXdY023944 for ; Mon, 17 Jan 2005 12:15:34 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 34so803590rns for ; Mon, 17 Jan 2005 12:15: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=L52uuD4dHrQkL0UdDALBixlpbCMnrRRoq1ZmFrn4T9964OTnK9xMJ0YXiwSF9d0btvNubrZptSHHaRlbW0eXslivTep6QHbM7Xsea78Md5muk+lUfWeyRGZ+ilaQ/oznJmly/FPRe6V9KGBLobI/VrGe0NIGuHYjzpy+DGv85Yw= Received: by 10.38.179.33 with SMTP id b33mr401505rnf; Mon, 17 Jan 2005 12:15:33 -0800 (PST) Received: by 10.38.179.71 with HTTP; Mon, 17 Jan 2005 12:15:32 -0800 (PST) Message-ID: <1f2ed5cd05011712154e9ed590@mail.gmail.com> Date: Mon, 17 Jan 2005 21:15:32 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Sam Ruby Subject: Re: AtomOWL & AtomIsRDF Cc: Henry Story , Atom WG In-Reply-To: <41EC1429.2060503@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <44B27E00-689A-11D9-993A-000A95D9FA7A@bblfish.net> <20050117171636.GK28196@homer.w3.org> <8D14E560-68AE-11D9-993A-000A95D9FA7A@bblfish.net> <41EC1429.2060503@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 17 Jan 2005 14:38:17 -0500, Sam Ruby wrote: > For starters, the current atom:generator element has optional "uri" and > "version" elements, not "atom:uri" and "atom:version" elements. > Unfortunately, these are quite different. Yurk, nice catch. I wonder if it might make sense (over on the RDF side of the transform/fence) to notionally define namespace-qualified terms as equivalent to the no-namespace ones in Atom syntax - that shouldn't impact anything on the Atom side, should it? > More siginificantly, the document does not address the largest issue, > which is content. Anything in particular in mind? I think there may be a very clean mapping of the content by simply taking the typing as used in Atom, defining each through XML Schema, then using URIs for each as the value for rdf:datatype in literals. It sounds complicated but in effect it should mean something like e.g. type="XHTML" being replaced by rdf:datatype="http://purl.org/atom/datatypes#XHTML", the rest of the RDF/XML syntax being near-identical to Atom. Whether this is actually possible is another matter...depends on the XML Schema datatype business, and whether it's consistent with the best practices draft in [1] (XML Schema Datatypes in RDF and OWL) - I've not had chance to read yet.. The alternative would seem to be to add the type as simply another literal-valued property of the content. Easy-peasy in principal and practice, but less elegant and a step removed from Henry's AtomAsRDF. > I do believe that it would be possible, and perhaps quite useful, to > define an XSLT tranform from Atom/XML to RDF/XML. Yep. Has anyone got one more recent than 0.3? Cheers, Danny. [1] http://www.w3.org/2001/sw/BestPractices/XSCH/xsch-sw-20041216/ -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Mon Jan 17 15:25: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 PAA11472 for ; Mon, 17 Jan 2005 15:25: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 j0HKGHE5024665; Mon, 17 Jan 2005 12:16: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 j0HKGHAI024664; Mon, 17 Jan 2005 12:16:17 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0HKGGFk024506 for ; Mon, 17 Jan 2005 12:16:16 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta04-winn.mailhost.ntl.com ([212.250.162.8]) by mta13-winn.mailhost.ntl.com with ESMTP id <20050117201609.TBHA10495.mta13-winn.mailhost.ntl.com@aamta04-winn.mailhost.ntl.com>; Mon, 17 Jan 2005 20:16:10 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta04-winn.mailhost.ntl.com with ESMTP id <20050117201608.GZAB13480.aamta04-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Mon, 17 Jan 2005 20:16:08 +0000 Date: Mon, 17 Jan 2005 20:16:05 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <1111904305.20050117201605@djpowell.net> To: "Bob Wyman" CC: "'Atom Syntax'" Subject: Re: Posted PaceSimpleLanguageTagging In-Reply-To: <200501171933.CJH90801@ms8.netsolmail.com> References: <1863472781.20050115173047@djpowell.net> <200501171933.CJH90801@ms8.netsolmail.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 Monday, January 17, 2005, 7:32:48 PM, you wrote: > There are some fields in Atom which are "language-independent" or > "neutral" and thus it might be useful to explicitly prevent the use of > xml:lang tags for these elements or simply state that they have no meaning > if used. It is the inheritance which I have the biggest problem with. > For instance, atom:id, atom:modified, atom:updated, have semantics > and syntax which is independent of language. However, all other fields > should be candidates for xml:lang. Which extension elements does it apply to? -- Dave From owner-atom-syntax@mail.imc.org Mon Jan 17 16:05: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 QAA14594 for ; Mon, 17 Jan 2005 16:05: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 j0HKr62O048278; Mon, 17 Jan 2005 12:53: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 j0HKr6LM048277; Mon, 17 Jan 2005 12:53:06 -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 j0HKr6Sv048270 for ; Mon, 17 Jan 2005 12:53:06 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 75488 invoked by uid 17064); 17 Jan 2005 20:53:06 -0000 Received: from unknown (HELO [192.168.0.7]) ([193.251.47.175]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 17 Jan 2005 20:53:06 -0000 In-Reply-To: <41EC1429.2060503@intertwingly.net> References: <44B27E00-689A-11D9-993A-000A95D9FA7A@bblfish.net> <20050117171636.GK28196@homer.w3.org> <8D14E560-68AE-11D9-993A-000A95D9FA7A@bblfish.net> <41EC1429.2060503@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7F809722-68C9-11D9-B24B-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: "'Atom WG'" From: Henry Story Subject: Re: AtomOWL & AtomIsRDF Date: Mon, 17 Jan 2005 21:51:02 +0100 To: Sam Ruby , Walter Underwood X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 17 Jan 2005, Walter Underwood wrote: > Call it "AtomAsRDF". That is indeed a much better name. Ok, off to change the page again... On 17 Jan 2005, at 20:38, Sam Ruby wrote: > Henry Story wrote: >> Yes, very good point. I have created a new Page called AtomRDF [3], >> whose aim >> is to track what would be needed for an Atom document to be an RDF >> document. > > I have a number of problems with the AtomRDF document as it stands now. > > For starters, the current atom:generator element has optional "uri" > and "version" elements, not "atom:uri" and "atom:version" elements. > Unfortunately, these are quite different. Oh God! I just looked this up in "Xml in a Nutshell". I had not realized that default namespaces did not apply to attributes. How awful! Is there any good reason for this? Any clever way to fix it? Otherwise why is XML broken like this? If there is no simple fix, I'll have to point this one out on the AtomRDF page as something to find a solution to. > More siginificantly, the document does not address the largest issue, > which is content. Can you expand a little on this. I have put this wiki up in order to serve as a reference point for all these problems. This is one I had not yet noticed, or not under your description at least. > > I do believe that it would be possible, and perhaps quite useful, to > define an XSLT tranform from Atom/XML to RDF/XML. Yes. The problem is that one can xslt transform something to many many different types of rdf/xml documents. Also the purpose of narrowing the gap between Atom and RDF down to 0 is that it would help give a very clear foundation for explaining extensibility, when combined with the AtomOWL ontology. The power of this is very similar to the power one gains with OO programming in creating frameworks. The relationship between OO programming and ontologies should be obvious from definition of ontology itself. "An explicit formal specification of how to represent the objects, concepts and other entities that are assumed to exist in some area of interest and the relationships that hold among them." [1] So yes. If we can narrow the gap, we can do Object Oriented XML development: which is way cool. (No fear, OO xml looks like plain old xml btw) One solution may be to have what we could call a canonical Atom format that would present an Atom document in a clean RDF way. This format would perhaps require that all attributes be in the atom namespace. Henry Story [1] http://dictionary.reference.com/search?q=ontology from the online dictionary of computing. From owner-atom-syntax@mail.imc.org Mon Jan 17 16: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 QAA20641 for ; Mon, 17 Jan 2005 16: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 j0HLWrnq065912; Mon, 17 Jan 2005 13:32: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 j0HLWrVe065911; Mon, 17 Jan 2005 13:32: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 j0HLWqi7065894 for ; Mon, 17 Jan 2005 13:32: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 1CqeTl-0001ng-KT; Mon, 17 Jan 2005 21:32:05 +0000 Message-ID: <41EC2F01.3060108@franklinmint.fm> Date: Mon, 17 Jan 2005 16:32:49 -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 , David Powell Subject: Re: Posted PaceSimpleLanguageTagging References: <1863472781.20050115173047@djpowell.net> <95C3A462-6852-11D9-B581-000A95A51C9E@sun.com> <1357402830.20050117084731@djpowell.net> <31C9992B-68B3-11D9-A757-000A95A51C9E@sun.com> <41EC0B08.20605@franklinmint.fm> <41EC0F3C.3010001@franklinmint.fm> <378CBA16-68BF-11D9-A757-000A95A51C9E@sun.com> In-Reply-To: <378CBA16-68BF-11D9-A757-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: > > Draft format-04 says "Requirements regarding the content and > interpretation of xml:lang are specified in XML 1.0 > [W3C.REC-xml-20040204] Section 2.12." If the element or attribute so > labeled contains free text, xml:lang is relevant. If not, not. If you > don't know (i.e. on some other-namespace exception), you'd better > preserve it. > I'm not disputing your observations on the semantics of xml:lang, but I find that last sentence unacceptable and unrealistic in the context of the larger discussion on extensibility. I'll try to illustrate why. Let's say a client generates the following Atom Entry Document to PUT at the server, which returns 204: ... time I think we can all agree that it would be acceptable for a subsequent GET to return this: ...time where the whitespace and comments are missing. So, not all aspects of the infoset must be preserved, nor must it be identical the original bytestream in the PUT. I think it should be acceptable to return the following: ...time This is why David (and myself) are pushing to define locations (head,entry,person) where extension content has special significance. Extensions would still be allowed at any location. However, if not located in one of the predefined locations, it could be discarded, because it's outside the "Atom model." Robert Sayre From owner-atom-syntax@mail.imc.org Mon Jan 17 16: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 QAA22235 for ; Mon, 17 Jan 2005 16: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 j0HLhCUD076345; Mon, 17 Jan 2005 13:43: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 j0HLhCBw076344; Mon, 17 Jan 2005 13:43:12 -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 j0HLhBRj076133 for ; Mon, 17 Jan 2005 13:43:12 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 54908 messnum 2830449 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 17 Jan 2005 21:43:05 -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 54908) with SMTP; 17 Jan 2005 21:43:05 -0000 Message-ID: <41EC3166.4070403@dehora.net> Date: Mon, 17 Jan 2005 21:43:02 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom WG Subject: Re: AtomOWL & AtomIsRDF References: <44B27E00-689A-11D9-993A-000A95D9FA7A@bblfish.net> <20050117171636.GK28196@homer.w3.org> <8D14E560-68AE-11D9-993A-000A95D9FA7A@bblfish.net> <41EC1429.2060503@intertwingly.net> <1f2ed5cd05011712154e9ed590@mail.gmail.com> In-Reply-To: <1f2ed5cd05011712154e9ed590@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 Danny Ayers wrote: > On Mon, 17 Jan 2005 14:38:17 -0500, Sam Ruby wrote: > >>I do believe that it would be possible, and perhaps quite useful, to >>define an XSLT tranform from Atom/XML to RDF/XML. > > > Yep. Has anyone got one more recent than 0.3? I'm waiting for the format to stabilize for publishing any mappings; my guess is that there are some Atom data structures that could see a lot of churn (links, dates, recursion) unless the consensus becomes 'enough already'. Incidently the name AtomIsRDF isn't as problematic as the latent assumption - that Atom is some of kind of degenerate or special case of RDF. My opinion is that's a losing strategy if the goal is wider adoption of RDF. cheers Bill From owner-atom-syntax@mail.imc.org Mon Jan 17 16: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 QAA22509 for ; Mon, 17 Jan 2005 16: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 j0HLfY05074447; Mon, 17 Jan 2005 13:41: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 j0HLfY8l074446; Mon, 17 Jan 2005 13:41:34 -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 j0HLfYqH074440 for ; Mon, 17 Jan 2005 13:41:34 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 18660 invoked by uid 17064); 17 Jan 2005 21:41:34 -0000 Received: from unknown (HELO [192.168.0.7]) ([193.253.244.16]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 17 Jan 2005 21:41:34 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <1f2ed5cd05011712154e9ed590@mail.gmail.com> References: <44B27E00-689A-11D9-993A-000A95D9FA7A@bblfish.net> <20050117171636.GK28196@homer.w3.org> <8D14E560-68AE-11D9-993A-000A95D9FA7A@bblfish.net> <41EC1429.2060503@intertwingly.net> <1f2ed5cd05011712154e9ed590@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8B7AC802-68D0-11D9-81F6-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: AtomOWL & AtomIsRDF Date: Mon, 17 Jan 2005 22:41:28 +0100 To: "'Atom WG'" X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit yes, and of course since OWL can specify mappings between the rdf vocabulary and the atom vocabulary it may even be possible to specify that atom:type is a sub property of rdf:datatype so that we end up with: atom:type="&atom;XHTML" Any further simplification ideas would be welcomed. The aim is to make the rdf as invisible as possible to anyone other than atom extension writers. If we have to bring out difficult rdf tools, so be it. Henry Story On 17 Jan 2005, at 21:15, Danny Ayers wrote: > > I think there may be a very clean mapping of the content by simply > taking the typing as used in Atom, defining each through XML Schema, > then using URIs for each as the value for rdf:datatype in literals. It > sounds complicated but in effect it should mean something like e.g. > type="XHTML" being replaced by > rdf:datatype="http://purl.org/atom/datatypes#XHTML", the rest of the > RDF/XML syntax being near-identical to Atom. From owner-atom-syntax@mail.imc.org Mon Jan 17 17:07: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 RAA27591 for ; Mon, 17 Jan 2005 17:07: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 j0HLuxCL088992; Mon, 17 Jan 2005 13:56: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 j0HLuxmp088991; Mon, 17 Jan 2005 13:56:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0HLuwjP088938 for ; Mon, 17 Jan 2005 13:56:59 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta03-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050117215653.GOUE22154.mta09-winn.mailhost.ntl.com@aamta03-winn.mailhost.ntl.com>; Mon, 17 Jan 2005 21:56:53 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta03-winn.mailhost.ntl.com with ESMTP id <20050117215653.UEMP9818.aamta03-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Mon, 17 Jan 2005 21:56:53 +0000 Date: Mon, 17 Jan 2005 21:56:50 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <861628472.20050117215650@djpowell.net> To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: Atom WG Subject: Re: AtomOWL & AtomIsRDF In-Reply-To: <41EC3166.4070403@dehora.net> References: <44B27E00-689A-11D9-993A-000A95D9FA7A@bblfish.net> <20050117171636.GK28196@homer.w3.org> <8D14E560-68AE-11D9-993A-000A95D9FA7A@bblfish.net> <41EC1429.2060503@intertwingly.net> <1f2ed5cd05011712154e9ed590@mail.gmail.com> <41EC3166.4070403@dehora.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 Monday, January 17, 2005, 9:43:02 PM, you wrote: > Danny Ayers wrote: >> On Mon, 17 Jan 2005 14:38:17 -0500, Sam Ruby wrote: >> >>>I do believe that it would be possible, and perhaps quite useful, to >>>define an XSLT tranform from Atom/XML to RDF/XML. >> >> >> Yep. Has anyone got one more recent than 0.3? > I'm waiting for the format to stabilize for publishing any mappings; my > guess is that there are some Atom data structures that could see a lot > of churn (links, dates, recursion) unless the consensus becomes 'enough > already'. > Incidently the name AtomIsRDF isn't as problematic as the latent > assumption - that Atom is some of kind of degenerate or special case of > RDF. My opinion is that's a losing strategy if the goal is wider > adoption of RDF. > cheers > Bill I put together a quick hack the other day as an experiment to see if it was possible: http://djpowell.net/tmp/atom2rdf.xsl It supports -04 with PaceExtensionConstruct (treating all Structured Extensions as unknown, but preserving them for round-tripping). It doesn't handle xml:base or xml:lang yet. I'll put it on the Wiki when I've sorted it out, but here it is as a preview. -- Dave From owner-atom-syntax@mail.imc.org Mon Jan 17 17:39: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 RAA01316 for ; Mon, 17 Jan 2005 17:39: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 j0HMUYkL014990; Mon, 17 Jan 2005 14:30: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 j0HMKepK013682; Mon, 17 Jan 2005 14:20:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ixion.tartarus.org (ixion.tartarus.org [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0HMKdSZ013553 for ; Mon, 17 Jan 2005 14:20:39 -0800 (PST) (envelope-from james@ixion.tartarus.org) Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) for atom-syntax@imc.org id 1CqfEb-0007mL-00; Mon, 17 Jan 2005 22:20:29 +0000 Date: Mon, 17 Jan 2005 22:20:29 +0000 From: James Aylett To: Atom Syntax Subject: Re: Posted PaceSimpleLanguageTagging Message-ID: <20050117222029.GA26682@tartarus.org> Mail-Followup-To: James Aylett , Atom Syntax References: <1863472781.20050115173047@djpowell.net> <95C3A462-6852-11D9-B581-000A95A51C9E@sun.com> <1357402830.20050117084731@djpowell.net> <31C9992B-68B3-11D9-A757-000A95A51C9E@sun.com> <41EC0B08.20605@franklinmint.fm> <41EC0F3C.3010001@franklinmint.fm> <378CBA16-68BF-11D9-A757-000A95A51C9E@sun.com> <41EC2F01.3060108@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41EC2F01.3060108@franklinmint.fm> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Jan 17, 2005 at 04:32:49PM -0500, Robert Sayre wrote: > > ... > > time > > > I think it should be acceptable to return the following: > > ...time I agree. However, given: ---------------------------------------------------------------------- ... time ---------------------------------------------------------------------- what should happen? If that can be accepted, with the xml:lang silently dropped, then it makes it easy for implementors. (I don't particularly care what happens - this is pretty boundary for me - but it probably needs to be made clear, or at the very least unambiguously decipherable from the spec.) James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Mon Jan 17 17:46: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 RAA01889 for ; Mon, 17 Jan 2005 17:46: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 j0HMco0c015800; Mon, 17 Jan 2005 14:38: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 j0HMcofP015799; Mon, 17 Jan 2005 14:38: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 j0HMcodX015792 for ; Mon, 17 Jan 2005 14:38:50 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 92200 invoked by uid 17064); 17 Jan 2005 22:38:49 -0000 Received: from unknown (HELO [192.168.0.7]) ([193.253.244.188]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 17 Jan 2005 22:38:49 -0000 In-Reply-To: <41EC3166.4070403@dehora.net> References: <44B27E00-689A-11D9-993A-000A95D9FA7A@bblfish.net> <20050117171636.GK28196@homer.w3.org> <8D14E560-68AE-11D9-993A-000A95D9FA7A@bblfish.net> <41EC1429.2060503@intertwingly.net> <1f2ed5cd05011712154e9ed590@mail.gmail.com> <41EC3166.4070403@dehora.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <8EE24B5B-68D8-11D9-81F6-000A95D9FA7A@bblfish.net> Cc: Atom WG From: Henry Story Subject: Re: AtomOWL & AtomAsRDF Date: Mon, 17 Jan 2005 23:38:50 +0100 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0HMcodX015793 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit The goal is not at all the wider adoption of RDF. The way I am proposing atom be seen as RDF will hopefully be completely invisible to anyone who does not know that it is. The point of being able to - if you will allow me the C,C++ idiom - cast an atom document to RDF will be to make it clear how to structure extensions. RDF alone does not do this, but RDF and the AtomOWL ontology does. It does this in a way that all Object Oriented programming languages do this: by specifying how concepts hook together. Take for example the following extension proposed recently tag://sometag 10.1 57.3 ... this implies the following rdf graph _e -entry-> _E |-id--> |-geo:x->"10.1" |-geo:y->"57.3" which presumably would mean that _E had to be both an Entry and a geographical location, which is a very unintuitive concept, and very likely *not* what the extension author intended. It would for example meant that this object would be a different object if it had a different id. What he probably intended was either - That the author was at some particular location, in which case he should probably have added attributes to the author object, through some foaf ontology predicate. - Or that some event the Entry is about was at some particular location. In which case this should have gone into the space by using an event ontology. Eg: _e --content-> _event --is-a-> |---location--->_loc --is-a-> |--geo:x-->"10.1" |--geo:y-->"57.3" The Object of the content predicate can accept anything (in java this would be a method that returned an Object), so it can accept among other things an xxx:Event. If you look at the AtomOWL spec, you will see that among other things it is simply a specification of what types of objects a relation can take as subject and as Object. Now we could define other mappings from xml to RDF. I have put forward some proposals that I think could bring this much closer to the intuitions of Tim Bray as expressed on this list. But we just don't have time. And since Atom is anyways so close to being RDF, I think the easiest route is simply to use the work done by others. I think the price is pretty minimal. And we will end up with a format that is extensible and even better defined than RSS1.0 Henry Story On 17 Jan 2005, at 22:43, Bill de hÓra wrote: > Incidently the name AtomIsRDF isn't as problematic as the latent > assumption - that Atom is some of kind of degenerate or special case > of RDF. My opinion is that's a losing strategy if the goal is wider > adoption of RDF. From owner-atom-syntax@mail.imc.org Mon Jan 17 18:08: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 SAA03736 for ; Mon, 17 Jan 2005 18: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 j0HMwLRt017997; Mon, 17 Jan 2005 14:58: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 j0HMwLKr017996; Mon, 17 Jan 2005 14:58: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0HMwJKu017974 for ; Mon, 17 Jan 2005 14:58:21 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id r35so20033rna for ; Mon, 17 Jan 2005 14:58:14 -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=RHglrNMQiS4ORC/TDzBO5QnR/zerFY+sd0uhDUi2CzPDELImtH9rNvKrbFdAfXWHkrDaH/kayVi5z/Y36inNCB8D531IrTl7v5wgDIayhyA7euRL0RnzgpjcoEOh0NehxBAmL/0KSMZ5b5sFUUXyJ/sOf/F/J7RmS1klVwygDxA= Received: by 10.38.161.60 with SMTP id j60mr80326rne; Mon, 17 Jan 2005 14:58:13 -0800 (PST) Received: by 10.38.72.20 with HTTP; Mon, 17 Jan 2005 14:58:12 -0800 (PST) Message-ID: <2bcdc7c405011714581de3638b@mail.gmail.com> Date: Mon, 17 Jan 2005 14:58:12 -0800 From: James Snell Reply-To: James Snell To: Atom Syntax Subject: Re: Please Review: Dissemination of Earthquake / Tsunami data via Atom In-Reply-To: <200501151800.j0FI0d1g032683@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <000001c4fb47$0b206a20$4542003e@zivchome> <200501151800.j0FI0d1g032683@nic-naa.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit What I'm wondering here is whether or not a or element could be used for this purpose. The element would be used within an entry to indicate that the entry has been retracted. The element would be used within a second entry to identify it as a retraction for some preceding entry. For example: ... urn:my-entry-1 2005-01-07T12:00:00-8:00 ... ... urn:my-entry-2 urn:my-entry-1 The retraction elements can be defined externally to the Atom core. On Sat, 15 Jan 2005 18:00:39 +0000, Eric Brunner-Williams in Portland Maine wrote: > > um... cancel messages? > > look, errors or state change repudiation is latent in all reported state. > why "un-write" when you can "later-write"? > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Mon Jan 17 19:13: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 TAA08173 for ; Mon, 17 Jan 2005 19:13: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 j0I00Ksf041384; Mon, 17 Jan 2005 16:00: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 j0I00KsP041383; Mon, 17 Jan 2005 16:00: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 j0I00HYL041375 for ; Mon, 17 Jan 2005 16:00:19 -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 j0I00HVu023468 for ; Mon, 17 Jan 2005 17:00:17 -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 <0IAH007L0K0GIF@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 17 Jan 2005 17:00:17 -0700 (MST) Received: from [192.168.1.30] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAH000JAK0G7R@mail.sun.net> for atom-syntax@imc.org; Mon, 17 Jan 2005 17:00:16 -0700 (MST) Date: Mon, 17 Jan 2005 16:00:27 -0800 From: Tim Bray Subject: Re: Posted PaceExtensionConstruct In-reply-to: <1758320721.20050115184717@djpowell.net> To: David Powell Cc: 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: <1113271276.20050112211950@djpowell.net> <1758320721.20050115184717@djpowell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 15, 2005, at 10:47 AM, David Powell wrote: > I've just updated this proposal thanks to some of the feedback that I > received. There is a change history at the end of the document. I'm OK with this. Also OK without it, but I gather that it would improve some people's comfort levels. Anyone against, as it now stands? -Tim From owner-atom-syntax@mail.imc.org Mon Jan 17 19:13: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 TAA08193 for ; Mon, 17 Jan 2005 19:13: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 j0I06ftG041823; Mon, 17 Jan 2005 16:06: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 j0I06fbU041822; Mon, 17 Jan 2005 16:06:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0I06cIt041768 for ; Mon, 17 Jan 2005 16:06:39 -0800 (PST) (envelope-from ga-atom-syntax@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Cqgt7-0003PU-00 for ; Tue, 18 Jan 2005 01:06:25 +0100 Received: from corp-fw-main.jabber.com ([207.182.164.14]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Jan 2005 01:06:25 +0100 Received: from stpeter by corp-fw-main.jabber.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Jan 2005 01:06:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: atom-syntax@imc.org From: Peter Saint-Andre Subject: Fwd: I-D ACTION:draft-saintandre-atompub-notify-02.txt Date: Mon, 17 Jan 2005 17:06:13 -0700 Organization: Jabber Software Foundation Lines: 85 Message-ID: X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: corp-fw-main.jabber.com User-Agent: MT-NewsWatcher/3.4 (PPC Mac OS X) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: FYI, I've added support for PaceHeadInEntry to the Atom-Over-XMPP spec... Peter ****** > From: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-saintandre-atompub-notify-02.txt > Date: Mon, 17 Jan 2005 16:06:39 -0500 > Newsgroups: gmane.ietf.announce > Message-ID: <200501172106.QAA14788@ietf.org> > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Transporting Atom Notifications over the Extensible > Messaging and Presence Protocol (XMPP) > Author(s) : P. Saint-Andre, et al. > Filename : draft-saintandre-atompub-notify-02.txt > Pages : 13 > Date : 2005-1-17 > > This memo describes a method for notifying interested parties about > changes in syndicated information encapsulated in the Atom feed > format, where such notifications are delivered via an extension to > the Extensible Messaging and Presence Protocol (XMPP) for > publish-subscribe functionality. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-saintandre-atompub-notify-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-saintandre-atompub-notify-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-saintandre-atompub-notify-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > --------------------------------------------------------------------- > Content-Type: text/plain > Content-ID: <2005-1-17154007.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-saintandre-atompub-notify-02.txt > --------------------------------------------------------------------- > Content-Type: text/plain > Content-ID: <2005-1-17154007.I-D@ietf.org> > > --------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce From owner-atom-syntax@mail.imc.org Mon Jan 17 19:31: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 TAA09246 for ; Mon, 17 Jan 2005 19:31: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 j0I0ES5P042634; Mon, 17 Jan 2005 16:14: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 j0I0ESkH042633; Mon, 17 Jan 2005 16:14:28 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0I0ERdF042621 for ; Mon, 17 Jan 2005 16:14:27 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta01-winn.mailhost.ntl.com ([212.250.162.8]) by mta05-winn.mailhost.ntl.com with ESMTP id <20050118001422.UOTT24912.mta05-winn.mailhost.ntl.com@aamta01-winn.mailhost.ntl.com>; Tue, 18 Jan 2005 00:14:22 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta01-winn.mailhost.ntl.com with ESMTP id <20050118001422.FNLK15415.aamta01-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Tue, 18 Jan 2005 00:14:22 +0000 Date: Tue, 18 Jan 2005 00:14:18 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <1464503512.20050118001418@djpowell.net> To: Tim Bray CC: atom-syntax@imc.org Subject: Re: Posted PaceExtensionConstruct In-Reply-To: References: <1113271276.20050112211950@djpowell.net> <1758320721.20050115184717@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: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tuesday, January 18, 2005, 12:00:27 AM, you wrote: > On Jan 15, 2005, at 10:47 AM, David Powell wrote: >> I've just updated this proposal thanks to some of the feedback that I >> received. There is a change history at the end of the document. > I'm OK with this. Also OK without it, but I gather that it would > improve some people's comfort levels. Anyone against, as it now > stands? -Tim Beware, that if we decide that Simple Extensions constructs are affected by xml:lang, then we need to change it slightly. -- Dave From owner-atom-syntax@mail.imc.org Mon Jan 17 19: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 TAA09601 for ; Mon, 17 Jan 2005 19:39: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 j0I0Wts0045641; Mon, 17 Jan 2005 16:32: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 j0I0Wt4l045640; Mon, 17 Jan 2005 16:32:55 -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 j0I0Wsjk045629 for ; Mon, 17 Jan 2005 16:32:54 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 34so817981rns for ; Mon, 17 Jan 2005 16:32: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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=r8eWSjLr73U5gOWcc4ZTr1Tb/nvhwtgwFJ/eesPXHq8aw+7WdJKSUFxB1LaL35KDC62srp0npktWmT6qDlABJV4L3nAx3t+DruNk1ByWd40BGe4gba6XlUGc/NC7R2IBxlTuopGGM1uWna61G3URYEDLVjhjCPlnDaxQn6mNw3s= Received: by 10.38.179.33 with SMTP id b33mr476992rnf; Mon, 17 Jan 2005 16:26:09 -0800 (PST) Received: by 10.38.179.71 with HTTP; Mon, 17 Jan 2005 16:26:09 -0800 (PST) Message-ID: <1f2ed5cd05011716265ce474b2@mail.gmail.com> Date: Tue, 18 Jan 2005 01:26:09 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Henry Story Subject: Re: AtomOWL & AtomAsRDF Cc: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom WG In-Reply-To: <8EE24B5B-68D8-11D9-81F6-000A95D9FA7A@bblfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <44B27E00-689A-11D9-993A-000A95D9FA7A@bblfish.net> <20050117171636.GK28196@homer.w3.org> <8D14E560-68AE-11D9-993A-000A95D9FA7A@bblfish.net> <41EC1429.2060503@intertwingly.net> <1f2ed5cd05011712154e9ed590@mail.gmail.com> <41EC3166.4070403@dehora.net> <8EE24B5B-68D8-11D9-81F6-000A95D9FA7A@bblfish.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 17 Jan 2005 23:38:50 +0100, Henry Story wrote: > Take for example the following extension proposed recently > > > tag://sometag > 10.1 > 57.3 > ... > > > this implies the following rdf graph > > _e -entry-> _E > |-id--> > |-geo:x->"10.1" > |-geo:y->"57.3" > > which presumably would mean that _E had to be both > an Entry and a geographical location, ...or an entry *with* a geographic location (or something completely different). which is a very > unintuitive concept, and very likely *not* what the > extension author intended. It would for example meant > that this object would be a different object if it had > a different id. > > What he probably intended was either > > - That the author was at some particular location, in which case he > should > probably have added attributes to the author object, through some foaf > ontology predicate. > > - Or that some event the Entry is about was at some particular > location. In which > case this should have gone into the space by using > an event > ontology. Maybe, but there's always the trade-off between accuracy of modelling and difficulty of handling the stuff. There's really nothing to stop the resource identified in being a geological event with a geographic location as well as something with a representation in the content of an entry in an Atom feed. The indirection can be reduced with the data expressing what the entry is, rather than what it is about. This example probably works better than most in human terms, as the entry could be an entry in an event log, though you could end up with the author of the feed entry being the creator of the earthquake... Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Mon Jan 17 19:48: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 TAA10251 for ; Mon, 17 Jan 2005 19:48: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 j0I0bdHd045966; Mon, 17 Jan 2005 16:37: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 j0I0bdif045965; Mon, 17 Jan 2005 16:37:39 -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 j0I0bcN6045954 for ; Mon, 17 Jan 2005 16:37:39 -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 j0I0bWTl013575; Mon, 17 Jan 2005 19:37:34 -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 CJJ26517 (AUTH bob@wyman.us); Mon, 17 Jan 2005 19:37:31 -0500 (EST) Message-Id: <200501180037.CJJ26517@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'James Snell'" , "'Atom Syntax'" Subject: RE: Please Review: Dissemination of Earthquake / Tsunami data via Atom Date: Mon, 17 Jan 2005 19:36:49 -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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcT86h1159zHTd+JTh+WItR77klG/QAB7mog In-Reply-To: <2bcdc7c405011714581de3638b@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James Snell wrote: > The element would be used within an entry to indicate that > the entry has been retracted. I must admit that I find myself going around in circles concerning this issue of retractions. I may be overly analyzing this. In any case, the following is my current thinking (subject to change...) An Atom feed is a record of a stream of entries that have been published over time. Once a thing is published, that fact cannot be erased, retracted, etc. While you can't erase a message previously published, you can make it unavailable by removing it from the current feed and you can supercede previously read copies of the entry by publishing a new entry that shares the same atom:id as the original. I think would only make sense if there was some semantic associated with that wasn't implied by republishing the entry. I can't think of any useful semantics that replacement doesn't provide. There is, however, one problem that bothers me a bit... Atom requires that an entry has a "rel='alternate'" link. However, when I'm trying to remove something (such as an erroneous earthquake report), I want to delete any HTML pages that might have been created for the deleted event. Once something is deleted, I can see that I need to communicate that fact in the feed, however, it doesn't seem right that I should have to clutter my site with all sorts of dead pages... Or, should I just have the retracting entry point to a standard "Entry Retracted" page that is shared by all retracted entries? (i.e. http://example.com/no_such_page.html ) bob wyman From owner-atom-syntax@mail.imc.org Mon Jan 17 20:28: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 UAA12834 for ; Mon, 17 Jan 2005 20:28: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 j0I1IO68049513; Mon, 17 Jan 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 j0I1IOsH049512; Mon, 17 Jan 2005 17:18:24 -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 j0I1INPX049502 for ; Mon, 17 Jan 2005 17:18:23 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 99663 messnum 6487377 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 18 Jan 2005 01:18:17 -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 99663) with SMTP; 18 Jan 2005 01:18:17 -0000 Message-ID: <41EC63D5.70604@dehora.net> Date: Tue, 18 Jan 2005 01:18:13 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom WG Subject: Re: AtomOWL & AtomAsRDF References: <44B27E00-689A-11D9-993A-000A95D9FA7A@bblfish.net> <20050117171636.GK28196@homer.w3.org> <8D14E560-68AE-11D9-993A-000A95D9FA7A@bblfish.net> <41EC1429.2060503@intertwingly.net> <1f2ed5cd05011712154e9ed590@mail.gmail.com> <41EC3166.4070403@dehora.net> <8EE24B5B-68D8-11D9-81F6-000A95D9FA7A@bblfish.net> In-Reply-To: <8EE24B5B-68D8-11D9-81F6-000A95D9FA7A@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: > this implies the following rdf graph > > _e -entry-> _E > |-id--> > |-geo:x->"10.1" > |-geo:y->"57.3" [On a technical point, I would disagree the graph is implied. As I said earlier, this kind of assumption concerns me.] > If you look at the AtomOWL spec, you will see that among other things it > is simply a specification of what types of objects a relation can take > as subject and as Object. > This is what I'm getting from the proposal - if range and domain for extensions are determined, a semantically 'consistent' (I won't say 'meaningful') extensibility framework for applying them to Atom structures can be established. So since we have evaluation rules above the level of data structures, we can determine if any extra metadata satisfies the constraints. Two things come to mind if that is a fair summary. First, I don't see how it can be done generally without RDF backed ontological modeling to begin with - which would be AtomIsRDF. Correct me if I'm wrong, but I think for this to work I would need to know what the essence of Atom domain constructs are before I can determine whether a new property can be correctly be applied to one. Second, I've said before, my position is that Atom doesn't require extensibility. Tim for one, has taken umbrage with my use of the word 'extensible', but what you're proposing isn't far away from what I would mean by it - extensions and their relationships are processed through an evaluator. I just happen to think we don't need to spec this yet*. So, I'm not -1 on this, but I do think it's out of scope. cheers Bill * I would include trying to make explicit whatever the child_of() evaluation rules might be for XML containership here. From owner-atom-syntax@mail.imc.org Tue Jan 18 02: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 CAA20610 for ; Tue, 18 Jan 2005 02: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 j0I71Dp7048129; Mon, 17 Jan 2005 23:01: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 j0I71CnZ048126; Mon, 17 Jan 2005 23:01:12 -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 j0I71Cb1048115 for ; Mon, 17 Jan 2005 23:01:12 -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 6F3764EFB4; Tue, 18 Jan 2005 02:01:11 -0500 (EST) Message-Id: <6.0.0.20.2.20050118152605.041289b0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 18 Jan 2005 15:56:28 +0900 To: David Powell From: Martin Duerst Subject: Re: Posted PaceSimpleLanguageTagging Cc: Atom Syntax In-Reply-To: <1316945519.20050117084730@djpowell.net> References: <1863472781.20050115173047@djpowell.net> <6.0.0.20.2.20050117135912.074ec2f8@localhost> <1316945519.20050117084730@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 At 17:47 05/01/17, David Powell wrote: >Reading the XML spec, I'm not clear that we're allowed to restrict the >inheritance of xml:lang? > >>From the spec: > >> The intent declared with xml:lang is considered to apply to all >> attributes and content of the element where it is specified, unless >> overridden with an instance of xml:lang on another element within >> that content. From this text, it is indeed not clear. There is an erratum that makes this clearer. Please see http://www.w3.org/XML/xml-V10-3e-errata#E01. >If we allow it to inherit inappropriately, and we restrict it to >certain elements, then this makes the situation even worse, as we'll >have no way of re-declaring or un-declaring xml:lang on elements that >it shouldn't apply to. I don't understand this. If the spec says that it doesn't apply to some element, there is no reason to un-declare it in the content, and of course even less a reason to re-declare it. Please also note that the current version of the XML spec allows xml:lang="", i.e. the empty string as a value to say that you don't have any information about the language. This is handy for cases like 1) the element is natural language text, but the actual content is e.g. only math or some other special notation that doesn't belong to a natural language, and 2) the actual content is natural language text, but the software doesn't know which language it is. As an aside: We should make sure that the Atom spec is very clear for each element that inherits (e.g. copyright,...) how to define the absence of such information. As experiece with xml:lang and other things has shown, having something like a 'reset' or 'neutral element' is extremely important every time there is inheritance, in particular for information that comes from different sources. >I think it is very unlikely that a user would want to include a title, >summary, and content in a different language. Well, somewhat unlikely, but not impossible. What about e.g. a service in Japan that takes some English feed and just changes the titles to Japanese for quicker browsing by a Japanese audience? >If we only allow xml:lang on Text constructs and atom:content, then >this means that the user would typically have to include it on titles, >summaries, and content separately. Would that be ok? Why have to do that for feeds that are completely or mostly monolingual? >Would it be any better than a dc:language style atom:language? Yes. It would still be better. >> As for RDF's support of xml:lang, there is a very RDF-specific, >> unfortunate issue that has to be taken into account when >> converting from atom to RDF/XML: RDF/XML at certain points >> cuts the inheritance of xml:lang. > >I didn't realize this - where is it? Ok, here it is: The RDF Graph model doesn't deal with mixed content (such as typical XHTML), but the data model has a special datatype that in RDF/XML is indicated by the rdf:parseType="Literal" attribute. The problem is that whenever you use this, RDF/XML requires you to cut language inheritance. From http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Literals: >>>> For text that may contain markup, use typed literals with type rdf:XMLLiteral. If language annotation is required, it must be explicitly included as markup, usually by means of an xml:lang attribute. [XHTML] may be included within RDF in this way. Sometimes, in this latter case, an additional span or div element is needed to carry an xml:lang or lang attribute. >>>> What this means in practice for Atom is that if it were not for this, you could just use a DTD to declare a default attribute of rdf:parseType="Literal" on things like . However, this won't work, because if you say <entry xml:lang='en'> ... <title>My entry title. ... which will look to a parser like ... My entry title. ... The XML Literal won't carry the language information. Even if you put the language information right on title, as so: ... My entry title. ... it still isn't picked up by RDF/XML. What RDF/XML requires you to do is something like ... <span xml:lang='en'>My entry title.</span> ... i.e. in order to give the language information to the title in RDF/XML, you have to introduce a 'dummy' element. This means that the simple DTD approach won't work, but such a transform of course can be done by XSLT. It also means that Henry and friends have some more work to define how Atom converts/relates to RDF, because they have to define when/how to introduce dummy elements. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Jan 18 02:14: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 CAA20635 for ; Tue, 18 Jan 2005 02:14: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 j0I71348048052; Mon, 17 Jan 2005 23:01: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 j0I713Bl048051; Mon, 17 Jan 2005 23:01:03 -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 j0I712Sa048040 for ; Mon, 17 Jan 2005 23:01:02 -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 4A0F54EFA4; Tue, 18 Jan 2005 02:01:00 -0500 (EST) Message-Id: <6.0.0.20.2.20050118150245.045ce9b0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 18 Jan 2005 15:06:14 +0900 To: David Powell , Tim Bray From: Martin Duerst Subject: Re: Posted PaceSimpleLanguageTagging Cc: Atom Syntax In-Reply-To: <644242235.20050117201554@djpowell.net> References: <1863472781.20050115173047@djpowell.net> <95C3A462-6852-11D9-B581-000A95A51C9E@sun.com> <1357402830.20050117084731@djpowell.net> <31C9992B-68B3-11D9-A757-000A95A51C9E@sun.com> <644242235.20050117201554@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 At 05:15 05/01/18, David Powell wrote: >Monday, January 17, 2005, 6:11:22 PM, you wrote: >> Suppose Joi Ito wants to list his name in >> Japanese but still write in English; or the the reverse. > >Let's hope he doesn't want to provide a name in more than one language. Well, I can definitely imagine situations where somebody like him may want to do that. >It isn't clear what xml:lang should apply to? Does it apply to email >addresses? Aural browsers might use it as a pronunciation hint. So >does a database implementation need an "email_lang" column in the >table or not? I think we need to decide on these issues rather than >leave it to implementors to guess. I think spelling out in the spec which elements take xml:lang and which ones don't, and which attributes it applies to and which not, would help. Anybody wants to start a list? Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Jan 18 02:15: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 CAA20926 for ; Tue, 18 Jan 2005 02:15: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 j0I70m1i047947; Mon, 17 Jan 2005 23:00: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 j0I70mr2047946; Mon, 17 Jan 2005 23:00:48 -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 j0I70mn3047931 for ; Mon, 17 Jan 2005 23:00:48 -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 09A514EFA4; Tue, 18 Jan 2005 02:00:44 -0500 (EST) Message-Id: <6.0.0.20.2.20050118135146.05830518@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 18 Jan 2005 14:39:33 +0900 To: Danny Ayers , atom-syntax@imc.org From: Martin Duerst Subject: Re: Content datatypes in XSD? In-Reply-To: <1f2ed5cd050117115414c91b@mail.gmail.com> References: <1f2ed5cd050117115414c91b@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 04:54 05/01/18, Danny Ayers wrote: > >It's been a long time since I looked at XML schemas, but would be >possible to express the content type attribute at all neatly using a >complex type? I imagine the "TEXT" | "HTML" | "XHTML" part would be >straightforward, but doesn't the | "pretty/much;anything" option screw >things up? It's not 'pretty much anything', it's a Mime media type. This can easily be defined with an XML Schema pattern. The "TEXT" | "HTML" | "XHTML" can also be made part of that pattern, or can be defined as an enumeration type and unioned with the media type pattern. Regards, Martin. >Cheers, >Danny. > >5.12.1 "type" attribute > > atom:content MAY have a "type" attribute, When present, the value MAY > be one of "TEXT", "HTML", or "XHTML". Failing that, it MUST be a > MIME media type [RFC2045] in which, to use the terminology of Section > 5 of [RFC2045], the top level is a discrete type. If the type > attribute is not provided, software MUST behave as though it were > present with a value of "TEXT". > >-- > >http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Jan 18 02:16: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 CAA21748 for ; Tue, 18 Jan 2005 02:16: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 j0I71B9j048108; Mon, 17 Jan 2005 23:01: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 j0I71Bpq048107; Mon, 17 Jan 2005 23:01:11 -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 j0I71ALN048099 for ; Mon, 17 Jan 2005 23:01:11 -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 414C14EFA4; Tue, 18 Jan 2005 02:01:06 -0500 (EST) Message-Id: <6.0.0.20.2.20050118150630.045d40e0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 18 Jan 2005 15:08:33 +0900 To: David Powell , "Bob Wyman" From: Martin Duerst Subject: Re: Posted PaceSimpleLanguageTagging Cc: "'Atom Syntax'" In-Reply-To: <1111904305.20050117201605@djpowell.net> References: <1863472781.20050115173047@djpowell.net> <200501171933.CJH90801@ms8.netsolmail.com> <1111904305.20050117201605@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 At 05:16 05/01/18, David Powell wrote: > > >Monday, January 17, 2005, 7:32:48 PM, you wrote: > >> There are some fields in Atom which are "language-independent" or >> "neutral" and thus it might be useful to explicitly prevent the use of >> xml:lang tags for these elements or simply state that they have no meaning >> if used. > >It is the inheritance which I have the biggest problem with. Why? It seems silly to mark each and every entry (or even worse, each and every title and content) in a feed as xml:lang="en" if most or all of them are in English. We have other things that get inherited from the feed to the entries, so I don't see why this one would be such a problem. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Jan 18 03:15: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 DAA28866 for ; Tue, 18 Jan 2005 03:15: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 j0I82mDG073097; Tue, 18 Jan 2005 00: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 j0I82mjN073095; Tue, 18 Jan 2005 00:02:48 -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 j0I82lED073085 for ; Tue, 18 Jan 2005 00:02:47 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 51992 invoked by uid 17064); 18 Jan 2005 08:02:25 -0000 Received: from unknown (HELO [192.168.0.7]) ([193.253.244.202]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 18 Jan 2005 08:02:25 -0000 In-Reply-To: <41EC63D5.70604@dehora.net> References: <44B27E00-689A-11D9-993A-000A95D9FA7A@bblfish.net> <20050117171636.GK28196@homer.w3.org> <8D14E560-68AE-11D9-993A-000A95D9FA7A@bblfish.net> <41EC1429.2060503@intertwingly.net> <1f2ed5cd05011712154e9ed590@mail.gmail.com> <41EC3166.4070403@dehora.net> <8EE24B5B-68D8-11D9-81F6-000A95D9FA7A@bblfish.net> <41EC63D5.70604@dehora.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <44AF9A25-6927-11D9-81F6-000A95D9FA7A@bblfish.net> Cc: Atom WG From: Henry Story Subject: Re: AtomOWL & AtomAsRDF Date: Tue, 18 Jan 2005 09:02:16 +0100 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0I82lED073086 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 18 Jan 2005, at 02:18, Bill de hÓra wrote: > Henry Story wrote: > >> this implies the following rdf graph >> _e -entry-> _E >> |-id--> >> |-geo:x->"10.1" >> |-geo:y->"57.3" > > [On a technical point, I would disagree the graph is implied. As I > said earlier, this kind of assumption concerns me.] It will be when the gap between atom as it currently is and where it would have to be for it to be correctly seen as RDF is closed. As you see there is not that much to closing the gap. And there are many ways of doing this, which need to be looked at, and evaluated for those that form the best compromise solution. >> If you look at the AtomOWL spec, you will see that among other things >> it >> is simply a specification of what types of objects a relation can take >> as subject and as Object. > > This is what I'm getting from the proposal - if range and domain for > extensions are determined, a semantically 'consistent' (I won't say > 'meaningful') extensibility framework for applying them to Atom > structures can be established. So since we have evaluation rules above > the level of data structures, we can determine if any extra metadata > satisfies the constraints. > > Two things come to mind if that is a fair summary. > > First, I don't see how it can be done generally without RDF backed > ontological modeling to begin with - which would be AtomIsRDF. Correct > me if I'm wrong, but I think for this to work I would need to know > what the essence of Atom domain constructs are before I can determine > whether a new property can be correctly be applied to one. Yes, if I have understood you correctly. That is why I have AtomOWL which gives you the essence of the Atom domain constructs. For example it specifies that atom:id is functional, which says that two Entries are different if they have different ids. I have tried to express all the number constraints that the spec defines too, such as a Feed requiring one Header and no more. I call this AtomAsRDF rather than AtomIsRDF because the point is that we are trying to make this completely invisible for anyone who does not want to know, or has not yet had time to learn these constructs. > Second, I've said before, my position is that Atom doesn't require > extensibility. Tim for one, has taken umbrage with my use of the word > 'extensible', but what you're proposing isn't far away from what I > would mean by it - extensions and their relationships are processed > through an evaluator. I just happen to think we don't need to spec > this yet*. I think that the spec does speak about extensibility and a model for atom. With AtomAsRDF and AtomOWL I provide both. Even if we did not need this yet, it certainly won't harm to track the differences, and the obvious problems that some decisions entail. For example modeling the Person construct it is obvious that the e-mail address should be "inverse functional" and not functional as we have it now. Ie if we have 2 Person objects (be they in an author or contributor tag) anywhere in the xml with the same email address, we should be able to conclude that these are in fact the same person. The model sometimes also can help spot gaps in the spec, which cannot be a bad thing. It is better these gaps be found now than later when it will be difficult to change anything. > So, I'm not -1 on this, but I do think it's out of scope. Ok. I take that as being that your kind of for it :-) By the way I think that there are many people out there who don't want to hear about RDF in so far as it is plastered all over their xml in big bold letters. They don't want rdf:li here and rdf:resource there. They don't want xml that is not in a nice tree shape, but just a set of statements about the relationship between things. They want to use XPath and other well tested tools. Apart from that they probably don't have anything really against RDF (apart from that one has the suspicion it could have been better done, but then that is true with all technologies - one need look no further than default namespaces in xml). So I think these people have nothing to worry about the current proposal. They have everything they want. And they have something extra: in their spare time they can learn about that weird thing called rdf. This would be seamless integration. And I think is the foundation of a good long lasting compromise. > cheers > Bill > > * I would include trying to make explicit whatever the child_of() > evaluation rules might be for XML containership here. > From owner-atom-syntax@mail.imc.org Tue Jan 18 03:18: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 DAA29126 for ; Tue, 18 Jan 2005 03:18: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 j0I86YvI074825; Tue, 18 Jan 2005 00:06: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 j0I86Y7f074824; Tue, 18 Jan 2005 00:06:34 -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 j0I86YhZ074815 for ; Tue, 18 Jan 2005 00:06:34 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 54970 invoked by uid 17064); 18 Jan 2005 08:06:34 -0000 Received: from unknown (HELO [192.168.0.7]) ([193.253.244.103]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 18 Jan 2005 08:06:34 -0000 In-Reply-To: <1f2ed5cd05011716265ce474b2@mail.gmail.com> References: <44B27E00-689A-11D9-993A-000A95D9FA7A@bblfish.net> <20050117171636.GK28196@homer.w3.org> <8D14E560-68AE-11D9-993A-000A95D9FA7A@bblfish.net> <41EC1429.2060503@intertwingly.net> <1f2ed5cd05011712154e9ed590@mail.gmail.com> <41EC3166.4070403@dehora.net> <8EE24B5B-68D8-11D9-81F6-000A95D9FA7A@bblfish.net> <1f2ed5cd05011716265ce474b2@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom WG From: Henry Story Subject: Re: AtomOWL & AtomAsRDF Date: Tue, 18 Jan 2005 09:06:16 +0100 To: Danny Ayers X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 18 Jan 2005, at 01:26, Danny Ayers wrote: > On Mon, 17 Jan 2005 23:38:50 +0100, Henry Story > wrote: > >> Take for example the following extension proposed recently >> >> >> tag://sometag >> 10.1 >> 57.3 >> ... >> >> >> this implies the following rdf graph >> >> _e -entry-> _E >> |-id--> >> |-geo:x->"10.1" >> |-geo:y->"57.3" >> >> which presumably would mean that _E had to be both >> an Entry and a geographical location, > > ...or an entry *with* a geographic location (or something completely > different). Yes. It all depends of course on how the geo ontology has defined its predicates. My point was to show a little how this gives a framework for extension writers to think about their extensions. It constrains extension writers the way logic constrains us in what we say, and that has never stopped people from speaking gibberish. It would probably help to work with a concrete example. That would show what effect each decision had, and give us a good way to discuss whether that was what the author intended. Perhaps we could start a thread taking a reasonable extension idea, and use that to discuss how they would be best off writing their extension in Atom+OWL. Henry From owner-atom-syntax@mail.imc.org Tue Jan 18 04:17: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 EAA03714 for ; Tue, 18 Jan 2005 04:17: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 j0I95Ujp000620; Tue, 18 Jan 2005 01:05: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 j0I95Ub6000618; Tue, 18 Jan 2005 01:05:30 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0I95TeR000531 for ; Tue, 18 Jan 2005 01:05:29 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta01-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050118090510.XRNW10802.mta08-winn.mailhost.ntl.com@aamta01-winn.mailhost.ntl.com>; Tue, 18 Jan 2005 09:05:10 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta01-winn.mailhost.ntl.com with ESMTP id <20050118090510.ZCAG15415.aamta01-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Tue, 18 Jan 2005 09:05:10 +0000 Date: Tue, 18 Jan 2005 09:05:07 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <1166128238.20050118090507@djpowell.net> To: Martin Duerst CC: Atom Syntax Subject: Re: Posted PaceSimpleLanguageTagging In-Reply-To: <6.0.0.20.2.20050118152605.041289b0@localhost> References: <1863472781.20050115173047@djpowell.net> <6.0.0.20.2.20050117135912.074ec2f8@localhost> <1316945519.20050117084730@djpowell.net> <6.0.0.20.2.20050118152605.041289b0@localhost> 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, January 18, 2005, 6:56:28 AM, you wrote: > At 17:47 05/01/17, David Powell wrote: >>Reading the XML spec, I'm not clear that we're allowed to restrict the >>inheritance of xml:lang? >> > From this text, it is indeed not clear. There is an erratum that > makes this clearer. Please see > http://www.w3.org/XML/xml-V10-3e-errata#E01. Good, that was one of the things that I was concerned about. > As an aside: We should make sure that the Atom spec is very > clear for each element that inherits (e.g. copyright,...) > how to define the absence of such information. As experiece > with xml:lang and other things has shown, having something > like a 'reset' or 'neutral element' is extremely important > every time there is inheritance, in particular for information > that comes from different sources. Yes, we should do this. I think extension elements are the main problem though. In PaceExtensionConstruct, I proposed two classes of extension. Simple Extension constructs were intended to be simple to interpret and implement. Should xml:lang apply to them? If it does, the range of the property would be a (string, language) pair, which would be useful for language sensitive text, but would be unnecessary for a lot of cases. Looking at the RSS1.0 list of extensions, most of them are not language dependant. If it didn't apply, then Structured Extension constructs could still be used to implement language sensitive text, but they are more opaque which would be a disadvantage. >>I didn't realize this - where is it? > Ok, here it is: The RDF Graph model doesn't deal with mixed content > (such as typical XHTML), but the data model has a special datatype > that in RDF/XML is indicated by the rdf:parseType="Literal" attribute. > The problem is that whenever you use this, RDF/XML requires you to > cut language inheritance. The solution for RDF that I was thinking of would be to add a BNode, and attach the parseType="Literal" content to it together with the xml:lang and xml:base context explicitly as properties; rather than modify the parseType="Literal" content. It would be like a virtual Content-Language / Content-Location header. BTW - Does a HTTP Content-Language set the default language for Atom? -- Dave From owner-atom-syntax@mail.imc.org Tue Jan 18 04:17: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 EAA03734 for ; Tue, 18 Jan 2005 04:17: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 j0I993Ls001911; Tue, 18 Jan 2005 01: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 j0I993J2001910; Tue, 18 Jan 2005 01:09:03 -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 j0I993a4001900 for ; Tue, 18 Jan 2005 01:09:03 -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 775A94EFC5; Tue, 18 Jan 2005 04:08:59 -0500 (EST) Message-Id: <6.0.0.20.2.20050118175656.0753d710@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 18 Jan 2005 17:57:36 +0900 To: Tim Bray , Graham From: Martin Duerst Subject: Re: format-04 HTML, diffs Cc: Robert Sayre , Atom-Syntax In-Reply-To: References: <41E43E05.7050009@franklinmint.fm> <4CCDD8E0-6436-11D9-B651-000A95DC3D90@mac.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 11:08 05/01/12, Tim Bray wrote: > >On Jan 11, 2005, at 5:07 PM, Graham wrote: > >> is mixing layers quite a bit. "The HTML markup must appear as text [in the infoset], such that it appears escaped in the XML source". > >Good idea I think... rather than the current convolutions around escaping and levels, talk about what ends up in the infoset. Ought to be clearer and more accurate. -Tim > Having some examples (of XML source, not infoset) would probably also help a lot. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Jan 18 04: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 EAA05557 for ; Tue, 18 Jan 2005 04:35: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 j0I9NBhL013712; Tue, 18 Jan 2005 01:23: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 j0I9NBXn013710; Tue, 18 Jan 2005 01:23:11 -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 j0I9NAQv013613 for ; Tue, 18 Jan 2005 01:23:10 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 9898 messnum 2050376 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 18 Jan 2005 09:23:04 -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 9898) with SMTP; 18 Jan 2005 09:23:04 -0000 Message-ID: <41ECD576.2010606@dehora.net> Date: Tue, 18 Jan 2005 09:23:02 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom WG Subject: Re: AtomOWL & AtomAsRDF References: <44B27E00-689A-11D9-993A-000A95D9FA7A@bblfish.net> <20050117171636.GK28196@homer.w3.org> <8D14E560-68AE-11D9-993A-000A95D9FA7A@bblfish.net> <41EC1429.2060503@intertwingly.net> <1f2ed5cd05011712154e9ed590@mail.gmail.com> <41EC3166.4070403@dehora.net> <8EE24B5B-68D8-11D9-81F6-000A95D9FA7A@bblfish.net> <41EC63D5.70604@dehora.net> <44AF9A25-6927-11D9-81F6-000A95D9FA7A@bblfish.net> In-Reply-To: <44AF9A25-6927-11D9-81F6-000A95D9FA7A@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: > Ok. I take that as being that your kind of for it :-) More than that; I think an ability to a) evaluate extensions in a uniform manner, b) determine if they are being applied appropriately, c) have the evaluation results output as more metadata, is immensely valuable. I think when you appreciate that value, the point of technologies like RDF become more apparent. But in my mind this work falls into innovation space rather than standards space. cheers Bill From owner-atom-syntax@mail.imc.org Tue Jan 18 11:30: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 LAA08326 for ; Tue, 18 Jan 2005 11:30: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 j0IGCXwp075455; Tue, 18 Jan 2005 08:12: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 j0IGCXtj075454; Tue, 18 Jan 2005 08:12:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0IGCVgM075446 for ; Tue, 18 Jan 2005 08:12:32 -0800 (PST) (envelope-from ga-atom-syntax@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Cqvy2-00064A-00 for ; Tue, 18 Jan 2005 17:12:30 +0100 Received: from corp-fw-main.jabber.com ([207.182.164.14]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Jan 2005 17:12:30 +0100 Received: from stpeter by corp-fw-main.jabber.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Jan 2005 17:12:30 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: atom-syntax@imc.org From: Peter Saint-Andre Subject: Re: Please Review: Dissemination of Earthquake / Tsunami data via Atom Date: Tue, 18 Jan 2005 09:12:09 -0700 Organization: Jabber Software Foundation Lines: 21 Message-ID: References: <2bcdc7c405011714581de3638b@mail.gmail.com> <200501180037.CJJ26517@ms8.netsolmail.com> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: corp-fw-main.jabber.com User-Agent: MT-NewsWatcher/3.4 (PPC Mac OS X) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In article <200501180037.CJJ26517@ms8.netsolmail.com>, "Bob Wyman" wrote: > There is, however, one problem that bothers me a bit... Atom > requires that an entry has a "rel='alternate'" link. However, when I'm > trying to remove something (such as an erroneous earthquake report), I want > to delete any HTML pages that might have been created for the deleted event. > Once something is deleted, I can see that I need to communicate that fact in > the feed, however, it doesn't seem right that I should have to clutter my > site with all sorts of dead pages... Or, should I just have the retracting > entry point to a standard "Entry Retracted" page that is shared by all > retracted entries? (i.e. http://example.com/no_such_page.html ) If the page once existed (especially if the topic was something as potentially momentous as a natural disaster warning), to me it seems best that attempting to retrieve the page would result in a redirect to the correct information, not a 404. Further thoughts on linkrot here: http://www.useit.com/alertbox/980614.html Peter From owner-atom-syntax@mail.imc.org Tue Jan 18 11:35: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 LAA08766 for ; Tue, 18 Jan 2005 11:35: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 j0IGPp6b079031; Tue, 18 Jan 2005 08:25: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 j0IGPpxU079030; Tue, 18 Jan 2005 08:25: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 j0IGPoiU079012 for ; Tue, 18 Jan 2005 08:25:50 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 57951 invoked by uid 17064); 18 Jan 2005 16:25:41 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.251.47.179]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 18 Jan 2005 16:25:41 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <41ED1669.6060306@infomesh.net> References: <41ED1669.6060306@infomesh.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <996FF586-696D-11D9-B0D5-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: RSS 1.1 Date: Tue, 18 Jan 2005 17:25:43 +0100 To: Atom WG X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ah. It looks like the RSS1.0 people are moving along. Their new format even has a small OWL file to go with it. I thought we could better them by having one first! Henry Story On 18 Jan 2005, at 15:00, Sean B. Palmer wrote: > I'm pleased to announce the release of RSS 1.1: a bugfix version of RSS > 1.0, being one of the most popular RDF applications to date. > > http://inamidst.com/rss1.1/ > - RSS 1.1 Specification > > This specification has been developed by a group of RSS 1.0 users > including myself who sought not just to resolve the various bugs > therein > but also to incorporate the latest features of RDF and improve the > integrity of the specification in general. > > To coincide with the release, we're also making available a number of > tools, including an RSS 1.1 feed validator, a converter, a test suite, > and various implementations for Movable Type, Wordpress, and others, > all > of which are linked to from the following guide: > > http://inamidst.com/rss1.1/guide > - A Rough Guide to RSS 1.1 > > Discussion of the format may be had in any of the following fora, > depending upon the particular nature of the feedback: > > * www-rdf-interest - Reply to this thread if you have comments about > the applicability of RDF to RSS in general, or RSS 1.1's specific > use of RDF features. > * irc.freenode.net #rss1.1 - For real time communication with the > developers of the specification, and any general comments. > * rss-dev mailing list: http://groups.yahoo.com/group/rss-dev/ > For feedback on how RSS 1.1 relates to 1.0 and other syndication > formats. > > Specific typographical corrections may be sent directly to the editors, > the contact details for whom are in the specification. > > Thanks, > > -- > Sean B. Palmer, http://inamidst.com/sbp/ > > From owner-atom-syntax@mail.imc.org Tue Jan 18 12:40: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 MAA14641 for ; Tue, 18 Jan 2005 12:40: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 j0IHTido087208; Tue, 18 Jan 2005 09:29: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 j0IHTibK087207; Tue, 18 Jan 2005 09:29: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.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0IHTgfc087198 for ; Tue, 18 Jan 2005 09:29:43 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so55960rnz for ; Tue, 18 Jan 2005 09:29: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:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=gYb3bRHF2P1PBqeIBvMc+++b9a0DIImI1d1ZgtTUgAaYJxmmQcaBL3oweKRO72tynwllay6alBOmJi/QKgp/yMZvuDE8Khyu89RU78pa+QlQU+MCNcBScqkTIdblqc6cAM9vd8fGqdWu8ju2uRx1N8iTt23lcC4iP3meMsjYPJo= Received: by 10.38.206.34 with SMTP id d34mr32939rng; Tue, 18 Jan 2005 09:29:41 -0800 (PST) Received: by 10.38.179.71 with HTTP; Tue, 18 Jan 2005 09:29:41 -0800 (PST) Message-ID: <1f2ed5cd05011809293e154ea1@mail.gmail.com> Date: Tue, 18 Jan 2005 18:29:41 +0100 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: Fwd: RSS 1.1 In-Reply-To: <41ED1669.6060306@infomesh.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41ED1669.6060306@infomesh.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ---------- Forwarded message ---------- From: Sean B. Palmer Date: Tue, 18 Jan 2005 14:00:09 +0000 Subject: RSS 1.1 To: www-rdf-interest@w3.org I'm pleased to announce the release of RSS 1.1: a bugfix version of RSS 1.0, being one of the most popular RDF applications to date. http://inamidst.com/rss1.1/ - RSS 1.1 Specification This specification has been developed by a group of RSS 1.0 users including myself who sought not just to resolve the various bugs therein but also to incorporate the latest features of RDF and improve the integrity of the specification in general. To coincide with the release, we're also making available a number of tools, including an RSS 1.1 feed validator, a converter, a test suite, and various implementations for Movable Type, Wordpress, and others, all of which are linked to from the following guide: http://inamidst.com/rss1.1/guide - A Rough Guide to RSS 1.1 Discussion of the format may be had in any of the following fora, depending upon the particular nature of the feedback: * www-rdf-interest - Reply to this thread if you have comments about the applicability of RDF to RSS in general, or RSS 1.1's specific use of RDF features. * irc.freenode.net #rss1.1 - For real time communication with the developers of the specification, and any general comments. * rss-dev mailing list: http://groups.yahoo.com/group/rss-dev/ For feedback on how RSS 1.1 relates to 1.0 and other syndication formats. Specific typographical corrections may be sent directly to the editors, the contact details for whom are in the specification. Thanks, -- Sean B. Palmer, http://inamidst.com/sbp/ -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Jan 18 14:11: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 OAA21199 for ; Tue, 18 Jan 2005 14:11: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 j0IIvI4N022541; Tue, 18 Jan 2005 10: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 j0IIvI60022540; Tue, 18 Jan 2005 10:57: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 ([161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0IIvHX6022467 for ; Tue, 18 Jan 2005 10:57: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 j0IItnsq017993; Tue, 18 Jan 2005 18:55:59 GMT In-Reply-To: <996FF586-696D-11D9-B0D5-000A95D9FA7A@bblfish.net> References: <41ED1669.6060306@infomesh.net> <996FF586-696D-11D9-B0D5-000A95D9FA7A@bblfish.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6-1065814723; protocol="application/pkcs7-signature" Message-Id: <91EBE2B7-6982-11D9-8050-000A95DC3D90@mac.com> Cc: Atom WG From: Graham Subject: Re: RSS 1.1 Date: Tue, 18 Jan 2005 18:55:49 +0000 To: Henry Story X-Mailer: Apple Mail (2.619) 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-1065814723 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 18 Jan 2005, at 4:25 pm, Henry Story wrote: >> http://inamidst.com/rss1.1/guide >> - A Rough Guide to RSS 1.1 They've removed the required stable identifier (rdf:about) from the entries, which was the main thing RSS 1.0 had going for it. Atom is now the only vaguely sensible format going. Graham --Apple-Mail-6-1065814723 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 9w0BCQUxDxcNMDUwMTE4MTg1NTUwWjAjBgkqhkiG9w0BCQQxFgQU+Brsx9hBC3Gkybkl4KK5Xokr RZUweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAbORmFtEWj35ooaDvvtvlTpmP 7VPyct4XWKjkL0Le96zIZC8Pe7Vw4vwESbct82QHVREmuhXBdx3anLNbPuXLAAAlMZKMAv1rETLI iuyNdCmt2a23NOWXt6XzM3uSRTuMKNUi5d+zeQTWL8kpTPHXN/o3N7ei2bCUkauU8U6H0Nn4FoG0 MyFFomyvqNB4QFsx9JNCxnD/LGpM5j+o008JBZ6/m6TfFNf6W+K0nb7qZn21NfEdOAHQmf9xUctB wluPlj2YZmE7gYoh0hPulkQdEHcQlkNm4Z+eQpompZHcLAFmKmWnxCn1lWcNqmab8CohcGd5m4Um ESby6thdrxHdcwAAAAAAAA== --Apple-Mail-6-1065814723-- From owner-atom-syntax@mail.imc.org Tue Jan 18 14:39: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 OAA23483 for ; Tue, 18 Jan 2005 14:39: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 j0IJRRTO036541; Tue, 18 Jan 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 j0IJRR9x036540; Tue, 18 Jan 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 priv-edtnes40.telusplanet.net (outbound05.telus.net [199.185.220.224]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0IJRQuR036493 for ; Tue, 18 Jan 2005 11:27:26 -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 <20050118192714.UIDC26483.priv-edtnes40.telusplanet.net@dora9> for ; Tue, 18 Jan 2005 12:27:14 -0700 Reply-To: From: "Jeremy Gray" To: "'Atom WG'" Subject: RE: RSS 1.1 Date: Tue, 18 Jan 2005 11:27:17 -0800 Message-ID: <000601c4fd93$ba615fa0$6400a8c0@dora9> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <91EBE2B7-6982-11D9-8050-000A95DC3D90@mac.com> Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0IJRQuR036534 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Graham > Sent: Tuesday, January 18, 2005 10:56 AM > To: Henry Story > Cc: Atom WG > Subject: Re: RSS 1.1 > > On 18 Jan 2005, at 4:25 pm, Henry Story wrote: > > >> http://inamidst.com/rss1.1/guide > >> - A Rough Guide to RSS 1.1 > > They've removed the required stable identifier (rdf:about) from the > entries, which was the main thing RSS 1.0 had going for it. I have yet to take more than a quick scan through the proposed RSS 1.1 specification, but I too noticed that backwards step. As a proponent of RDF and of RSS 1.0, I also noticed several other backwards steps* that I'll have to dig into when I have a bit more time. (* Even more constraints that make it even less useful to RDF-based systems, which makes no sense given that non-RDF systems are obviously going to go with Atom, leaving RSS 1.x in a position to become more RDF-focused, not less.) > Atom is now the only vaguely sensible format going. Other than RSS 1.0, of course. :) Jeremy Gray From owner-atom-syntax@mail.imc.org Tue Jan 18 17:53: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 RAA14632 for ; Tue, 18 Jan 2005 17:53: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 j0IMRKLv038110; Tue, 18 Jan 2005 14:27: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 j0IMRKG9038109; Tue, 18 Jan 2005 14:27:20 -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 (mailhost.ntl.com [212.250.162.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0IMRJPQ038025 for ; Tue, 18 Jan 2005 14:27:19 -0800 (PST) (envelope-from sean+rss@infomesh.net) Received: from aamta03-winn.mailhost.ntl.com ([212.250.162.8]) by mta05-winn.mailhost.ntl.com with ESMTP id <20050118222713.KOQJ15380.mta05-winn.mailhost.ntl.com@aamta03-winn.mailhost.ntl.com>; Tue, 18 Jan 2005 22:27:13 +0000 Received: from [192.168.1.100] (really [82.0.103.238]) by aamta03-winn.mailhost.ntl.com with ESMTP id <20050118222713.HHA9818.aamta03-winn.mailhost.ntl.com@[192.168.1.100]>; Tue, 18 Jan 2005 22:27:13 +0000 Message-ID: <41ED8D3D.8040901@infomesh.net> Date: Tue, 18 Jan 2005 22:27:09 +0000 From: "Sean B. Palmer" User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtcd@mac.com CC: atom-syntax@imc.org Subject: Re: RSS 1.1 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 > They've removed the required stable identifier (rdf:about) from the > entries, which was the main thing RSS 1.0 had going for it. Brent and Dare have already raised this, and it's being considered as a bug and dealt with. See the following for further details: http://lists.xml.org/archives/xml-dev/200501/msg00421.html Thanks, -- Sean B. Palmer, http://inamidst.com/sbp/ From owner-atom-syntax@mail.imc.org Tue Jan 18 19:34: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 TAA22814 for ; Tue, 18 Jan 2005 19:34: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 j0J0N7V4053796; Tue, 18 Jan 2005 16:23: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 j0J0N7u6053795; Tue, 18 Jan 2005 16:23:07 -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 j0J0N2TK053627 for ; Tue, 18 Jan 2005 16:23:07 -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 j0J0Mxdt028944 for ; Tue, 18 Jan 2005 17:23:00 -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 <0IAJ00301FJOL2@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Tue, 18 Jan 2005 19:22:59 -0500 (EST) Received: from localhost (d-usca14-133-118.SFBay.Sun.COM [129.145.133.118]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IAJ00M3AFQBR0@bur-mail1.east.sun.com> for atom-syntax@imc.org; Tue, 18 Jan 2005 19:22:59 -0500 (EST) Received: from ndw by localhost with local (Exim 4.34) id 1Cr3cg-0002r1-NQ for atom-syntax@imc.org; Tue, 18 Jan 2005 16:22:58 -0800 X-URL: http://nwalsh.com/ Date: Tue, 18 Jan 2005 16:22:56 -0800 From: Norman Walsh Subject: Re: AtomOWL & AtomIsRDF In-reply-to: <44B27E00-689A-11D9-993A-000A95D9FA7A@bblfish.net> To: Atom Syntax Message-id: <87sm4y6zdr.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: <44B27E00-689A-11D9-993A-000A95D9FA7A@bblfish.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 Just a note for this thread. I plan, eventually, to add the OWL mappings to my RELAX NG schema for Atom and, perhaps, to build a stylesheet that produces a stylesheet that does the conversion from those annotations. But I won't get started, I expect, until there's broader consensus on what the mapping should be. Be seeing you, norm =2D-=20 Norman Walsh | Never contend with a man who has http://nwalsh.com/ | nothing to lose.-- Graci=C3=A1n --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBB7ahiOyltUcwYWjsRAu8KAKCINZ0HjEBizUiLKIgP9m51AIlMWQCgkURN 9miWrxS2eaJCut/vENz1FPE= =35tf -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Wed Jan 19 04:57: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 EAA26239 for ; Wed, 19 Jan 2005 04:57: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 j0J9fcD4041965; Wed, 19 Jan 2005 01:41: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 j0J9fcwG041964; Wed, 19 Jan 2005 01:41:38 -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 j0J9fcCE041952 for ; Wed, 19 Jan 2005 01:41:38 -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 AEC574EF92; Wed, 19 Jan 2005 04:41:34 -0500 (EST) Message-Id: <6.0.0.20.2.20050119162200.06348798@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 19 Jan 2005 16:23:39 +0900 To: Danny Ayers , atom-syntax@imc.org From: Martin Duerst Subject: Re: Fwd: RSS 1.1 In-Reply-To: <1f2ed5cd05011809293e154ea1@mail.gmail.com> References: <41ED1669.6060306@infomesh.net> <1f2ed5cd05011809293e154ea1@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:29 05/01/19, Danny Ayers wrote: >From: Sean B. Palmer >I'm pleased to announce the release of RSS 1.1: a bugfix version of RSS >1.0, being one of the most popular RDF applications to date. > > http://inamidst.com/rss1.1/ > - RSS 1.1 Specification I note the progress from the RSS 1.0 Content Module (encoded) to the RSS 1.1 Payload Module (not encoded). I haven't studied the rest. Regards, Martin. From owner-atom-syntax@mail.imc.org Wed Jan 19 05:05: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 FAA26560 for ; Wed, 19 Jan 2005 05:05: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 j0J9cCq3036993; Wed, 19 Jan 2005 01: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 j0J9cCeH036992; Wed, 19 Jan 2005 01:38:12 -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 j0J9c8e7036759 for ; Wed, 19 Jan 2005 01:38:08 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 59771 invoked by uid 17064); 19 Jan 2005 09:38:04 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.251.47.195]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 19 Jan 2005 09:38:04 -0000 In-Reply-To: <9C395894-629F-11D9-B5EE-000D93324AD6@gbiv.com> References: <9C395894-629F-11D9-B5EE-000D93324AD6@gbiv.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom WG From: Henry Story Subject: Re: PaceFeedRecursive Date: Wed, 19 Jan 2005 10:38:04 +0100 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit How is this coming along? I think the current spec really would do with some good simplification. We have RSS1.1 to look at now, at it does look a hell of a lot simpler. (Don't want to start a RSS1.1 thread here please) 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 On 10 Jan 2005, at 01:36, Roy T. Fielding wrote: > > I just created a starting point for a proposal on making the > feed element recursive, eliminating the need for RDF syntax, > atom:head, and a bunch of things proposed in other paces regarding > aggregators and digital signatures. > > http://www.intertwingly.net/wiki/pie/PaceFeedRecursive > > Unfortunately, I have a paper deadline on Tuesday and can't > procrastinate any longer, so someone else can finish the details > or I'll finish it later in the week. > > > Cheers, > > Roy T. Fielding > Chief Scientist, Day Software > From owner-atom-syntax@mail.imc.org Wed Jan 19 05:29: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 FAA28898 for ; Wed, 19 Jan 2005 05: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 j0JAJ5W6084476; Wed, 19 Jan 2005 02:19: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 j0JAJ57L084475; Wed, 19 Jan 2005 02:19:05 -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 j0JAJ4bG084439 for ; Wed, 19 Jan 2005 02:19:04 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so47628rnz for ; Wed, 19 Jan 2005 02:18: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:to:subject:mime-version:content-type:content-transfer-encoding; b=g8QgeG0UrI05L4YUT8+KW9znDyVae0xfjKhkHOcn469NPiBilbS/XKi9/MOrONpBRQpkKueo2jChorrZHPVWCkXYJReX0+Cz5Nc2X0iN4dnIfTqCV9/O5Q1mxM7jm05o0Zo1hrE6xyqoc9/VijTktY5POOPC7204T2Esb8rybyc= Received: by 10.38.206.34 with SMTP id d34mr349646rng; Wed, 19 Jan 2005 02:18:58 -0800 (PST) Received: by 10.38.179.71 with HTTP; Wed, 19 Jan 2005 02:18:58 -0800 (PST) Message-ID: <1f2ed5cd0501190218252cdb8f@mail.gmail.com> Date: Wed, 19 Jan 2005 11:18:58 +0100 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: is URI? 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 don't know whether this is a little editorial oversight or something I missed/misremember - wasn't it agreed that the content of the element should be a URI - the spec currently 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. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Jan 19 05:46: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 FAA29968 for ; Wed, 19 Jan 2005 05:46: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 j0JAUiTj088988; Wed, 19 Jan 2005 02:30: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 j0JAUiKt088987; Wed, 19 Jan 2005 02:30:44 -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 j0JAUi3F088979 for ; Wed, 19 Jan 2005 02:30:44 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 14715 invoked by uid 17064); 19 Jan 2005 10:30:44 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.253.244.32]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 19 Jan 2005 10:30:44 -0000 In-Reply-To: <1f2ed5cd0501190218252cdb8f@mail.gmail.com> References: <1f2ed5cd0501190218252cdb8f@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <28848F1C-6A05-11D9-AC0C-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org From: Henry Story Subject: Re: is URI? Date: Wed, 19 Jan 2005 11:30:37 +0100 To: Danny Ayers X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I think that is specified in the IdentityConstruct section of the spec. In the OWL I just take that to be a RDF Resource. Henry On 19 Jan 2005, at 11:18, Danny Ayers wrote: > > I don't know whether this is a little editorial oversight or something > I missed/misremember - wasn't it agreed that the content of the > element should be a URI - the spec currently 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. > > Cheers, > Danny. > > -- > > http://dannyayers.com > From owner-atom-syntax@mail.imc.org Wed Jan 19 08:59: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 IAA13219 for ; Wed, 19 Jan 2005 08: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 j0JDeR2n065103; Wed, 19 Jan 2005 05:40: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 j0JDeRVO065102; Wed, 19 Jan 2005 05:40:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hannibal.dreamhost.com (postfix@hannibal.dreamhost.com [205.196.208.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0JDeOAR065096 for ; Wed, 19 Jan 2005 05:40:25 -0800 (PST) (envelope-from arve@virtuelvis.com) Received: from melkor (ti132110a080-0655.bb.online.no [80.212.210.143]) by hannibal.dreamhost.com (Postfix) with ESMTP id C5BF1175128; Wed, 19 Jan 2005 05:40:20 -0800 (PST) Date: Wed, 19 Jan 2005 14:40:17 +0100 To: atom-syntax@imc.org Subject: Revisiting feed discovery Cc: "Mark Pilgrim" From: "Arve Bersvendsen" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: 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 I have just reread the Atom autodiscovery protocol, at . I have also read , and I believe the autodiscovery protocol needs revisiting: a) rel="alternate" is a misnomer. Not all feeds are alternate content. They may have some other relationship, such as rel="related". b) Specifying a mime type for a feed is not always appropriate. If we are assuming that "Cool URIs don't change", requiring a type-attribute is a huge mistake: I) The MIME type of the feed may change over time. Feeds may migrate from being application/rss+xml to being application/atom+xml II) The MIME type may differ, depending on the client requesting it. I am currently running an experiment/survey with content-negotiated feeds, see [1] where I serve alternatively Atom/RSS 1.0/RSS 2.0 feeds to User-Agents depending on the Accept: header they are sending, and the preliminary data seems to suggest that using content-negotiation is a working means of serving feeds in multiple formats from a single URI. My suggestions: a) Change rel="alternate" to rel="feed", rel="subscription" or similar. b) Drop 'type' as a required attribute for link. Make it a 'MAY'. ___ [1] I also have a 'live' content-negotiated feed at that sends either application/rss+xml or application/atom+xml if a live experimental feed is wanted. -- Arve Bersvendsen http://virtuelvis.com From owner-atom-syntax@mail.imc.org Wed Jan 19 10:05: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 KAA19021 for ; Wed, 19 Jan 2005 10:05: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 j0JEqNEg076986; Wed, 19 Jan 2005 06:52: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 j0JEqNUd076985; Wed, 19 Jan 2005 06:52: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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0JEqMgt076978 for ; Wed, 19 Jan 2005 06:52:22 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so63832rnz for ; Wed, 19 Jan 2005 06:52:22 -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=ZGMDoEJ9CfmlhNjJqxN/pwgoSvhkREyTFDwIqui0qExe0iWGw959KSGHtUb9OHFlQv96IQ9Q05pqIzDToioK3eVfJHhpXT2TLJrCx3LTOssM9auyB9Tsjh/KRdJ+c1Xbx4ftrfKjxd3HaRvnGi9pwT7rgEKyL+cebI9n2cCQ+iw= Received: by 10.38.8.49 with SMTP id 49mr40769rnh; Wed, 19 Jan 2005 06:52:22 -0800 (PST) Received: by 10.38.179.71 with HTTP; Wed, 19 Jan 2005 06:52:22 -0800 (PST) Message-ID: <1f2ed5cd0501190652773943ff@mail.gmail.com> Date: Wed, 19 Jan 2005 15:52:22 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Arve Bersvendsen Subject: Re: Revisiting feed discovery Cc: atom-syntax@imc.org, Mark Pilgrim 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 Wed, 19 Jan 2005 14:40:17 +0100, Arve Bersvendsen wrote: > > I have just reread the Atom autodiscovery protocol, at > . > I have also read , and I believe > the autodiscovery protocol needs revisiting: > > a) rel="alternate" is a misnomer. Not all feeds are alternate content. > They may have some other relationship, such as rel="related". True. > b) Specifying a mime type for a feed is not always appropriate. If we are > assuming that "Cool URIs don't change", requiring a type-attribute is a > huge mistake: > I) The MIME type of the feed may change over time. Feeds may migrate > from being application/rss+xml to being application/atom+xml > II) The MIME type may differ, depending on the client requesting it. Re. II) I'm not so sure about this, it depends somewhat on how you interpret the element - I think an interpretation consistent with webarch could be: there's data of this mime type available from this URI (using a HTTP GET) Re. I) So? The publisher can simply update the link, as they'd have to for various other changes. > I am currently running an experiment/survey with content-negotiated feeds, > see [1] where I > serve alternatively Atom/RSS 1.0/RSS 2.0 feeds to User-Agents depending on > the Accept: header they are sending, and the preliminary data seems to > suggest that using content-negotiation is a working means of serving feeds > in multiple formats from a single URI. Nice work, this should be useful. > My suggestions: > > a) Change rel="alternate" to rel="feed", rel="subscription" or similar. > b) Drop 'type' as a required attribute for link. Make it a 'MAY'. On one (technical) level both make sense. However given that the current version is pretty widely deployed, a) at least could be counter-productive due to confusion. "alternate" might not be accurate in a lot of cases, but as a simple convention is near enough. I don't see much potential harm in b) but then again I don't see much benefit. If the feed is available in multiple formats (at the same or different URIs) then can't that be declared using multiple link elements? Overall, I'd conclude that it's not perfect but good enough as it stands. > [1] I also have a 'live' content-negotiated feed at > that sends either > application/rss+xml or application/atom+xml if a live experimental feed is > wanted. Any thoughts on "application/rdf+xml"? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Jan 19 10:29: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 KAA22090 for ; Wed, 19 Jan 2005 10:29: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 j0JFHlwi078973; Wed, 19 Jan 2005 07:17: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 j0JFHlo2078972; Wed, 19 Jan 2005 07:17: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 j0JFHfYP078959 for ; Wed, 19 Jan 2005 07:17:42 -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, 20 Jan 2005 04:18:23 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 20 Jan 2005 02:17:35 +1100 Subject: Re: Revisiting feed discovery From: Eric Scheid To: Atom Syntax CC: Mark Pilgrim , Arve Bersvendsen , Danny Ayers 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 j0JFHgYP078962 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 20/1/05 12:40 AM, "Arve Bersvendsen" wrote: > > I have just reread the Atom autodiscovery protocol, at > . > I have also read , and I believe > the autodiscovery protocol needs revisiting: > > a) rel="alternate" is a misnomer. Not all feeds are alternate content. > They may have some other relationship, such as rel="related". and not all 'alternate' content is a "feed", even if the mime-type="application/atom+xml". It could be an Atom Entry Document alternative to the HTML page for a given post. I wrote something about this just recently... you might have to skim past the initial rambling though... http://www.imc.org/atom-syntax/mail-archive/msg12058.html ... in that I suggested we might well need a new mime type for Atom Entry Documents. Shall I write a Pace? > My suggestions: > > a) Change rel="alternate" to rel="feed", rel="subscription" or similar. +1 for "feed", for the link to the resource which is a "sliding window representation" of the most recently updated content from which the current resource was once published via. Don't use "feed" for links to Atom Feed Documents which serve as a static archive (eg. "Posts for October 2004"). > b) Drop 'type' as a required attribute for link. Make it a 'MAY'. @type isn't a required attribute. 3.5.2 "type" Attribute Link constructs MAY have a type attribute, whose value MUST conform to the syntax of a MIME media type [RFC2045]. The type attribute's value is an advisory media type; it MAY be used as a hint to determine the type of the representation which is expected to be returned when the value of the href attribute is dereferenced. Note that the type attribute does not override the actual media type returned with the representation. e. From owner-atom-syntax@mail.imc.org Wed Jan 19 10:44: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 KAA23259 for ; Wed, 19 Jan 2005 10:44: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 j0JFTZUm080503; Wed, 19 Jan 2005 07:29: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 j0JFTZ8L080502; Wed, 19 Jan 2005 07:29:35 -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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0JFTYco080495 for ; Wed, 19 Jan 2005 07:29:34 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so67313rnz for ; Wed, 19 Jan 2005 07:29:34 -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=t4LEDJtgHtDerQgRAUVNMkeyI3BinZK7bs9naIHRKcWoYuxmksV0nNF+hhYoSAhvKuUBLSqNt+cyKYm3bYtMV0l6o891NRJcN19k8Wi3EVbUFNWSs8uASfqdyqwS3/uPpe3qs1M3sP+zT7OruUk8qJ8DrgI37c5sQIb05fhPaAY= Received: by 10.38.8.4 with SMTP id 4mr28547rnh; Wed, 19 Jan 2005 07:29:33 -0800 (PST) Received: by 10.38.179.71 with HTTP; Wed, 19 Jan 2005 07:29:33 -0800 (PST) Message-ID: <1f2ed5cd0501190729717d8e09@mail.gmail.com> Date: Wed, 19 Jan 2005 16:29:33 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Eric Scheid Subject: Re: Revisiting feed discovery Cc: Atom Syntax , Mark Pilgrim , Arve Bersvendsen , Danny Ayers 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 Thu, 20 Jan 2005 02:17:35 +1100, Eric Scheid wrote: > +1 for "feed", for the link to the resource which is a "sliding window > representation" of the most recently updated content from which the current > resource was once published via. Don't use "feed" for links to Atom Feed > Documents which serve as a static archive (eg. "Posts for October 2004"). Eww, that doesn't sound right at all - if I don't update my blog for ten years, do I have to change the attribute and mime type? I'd have opted for a single (Atom) mime type and the 'sliding window'/'static' nature being self-descriptive in the doc. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Jan 19 11: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 LAA24495 for ; Wed, 19 Jan 2005 11:05: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 j0JFqhwL086089; Wed, 19 Jan 2005 07:52: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 j0JFqhsw086088; Wed, 19 Jan 2005 07:52:43 -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 j0JFqfQu086082 for ; Wed, 19 Jan 2005 07:52:42 -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, 20 Jan 2005 04:53:24 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 20 Jan 2005 02:52:37 +1100 Subject: Re: Revisiting feed discovery From: Eric Scheid To: Danny Ayers , Atom Syntax Message-ID: In-Reply-To: <1f2ed5cd0501190729717d8e09@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 20/1/05 2:29 AM, "Danny Ayers" wrote: >> +1 for "feed", for the link to the resource which is a "sliding window >> representation" of the most recently updated content from which the current >> resource was once published via. Don't use "feed" for links to Atom Feed >> Documents which serve as a static archive (eg. "Posts for October 2004"). > > Eww, that doesn't sound right at all - if I don't update my blog for > ten years, do I have to change the attribute and mime type? I wouldn't think so. The distinction has to do with what the main purpose for auto-discovery links are for: finding a link to a resource which will act as a feed of future publishings. Which is different from finding a link to a resource which is the collection of all entries made in a specific date period. With the former, generally speaking, there is an expectation of "more to come", which with some authors could well be quite some time in the future (I have more than a few subscriptions in my feed-reader which haven't been updated for a long time, but absent any official closure they are still "feeds of more to come"). As to mime-type ... maybe I wasn't clear ... I meant one mime-type for Atom Feed Documents (whether "sliding window feeds" or "period archive" or whatever), and another mime-type for Atom Entry Documents. Thus you might see the following in one entry: ... the first link is to the "feed", while the second would be to a stand-alone resource which is an Atom Entry Document (not a feed). > I'd have > opted for a single (Atom) mime type and the 'sliding window'/'static' > nature being self-descriptive in the doc. Ah, but then we hit a snag with the "auto" part of "auto-discovery". If a single entry has links to the sliding window feed, the appropriate monthly archive, and also the Atom Entry Document, and they all have @rel="alternate" and @type="application/atom+xml", how would an agent know which one to subscribe to automatically. There's more to this than what I've briefly touched on above. I recommend you read my earlier message for more detail... it starts from a different starting point, but comes to the same conclusion http://www.imc.org/atom-syntax/mail-archive/msg12058.html It also suggests popularising Atom Entry Documents as a meta-data resource for html pages, which is a back-door method to popularising Atom as a Feed format. (This is something Atom has over RSS - the Atom Entry Document concept). e. From owner-atom-syntax@mail.imc.org Wed Jan 19 12:00: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 MAA28360 for ; Wed, 19 Jan 2005 12:00: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 j0JGnoBg091820; Wed, 19 Jan 2005 08:49: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 j0JGnoUi091819; Wed, 19 Jan 2005 08:49:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hannibal.dreamhost.com (postfix@hannibal.dreamhost.com [205.196.208.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0JGnmH9091811 for ; Wed, 19 Jan 2005 08:49:48 -0800 (PST) (envelope-from arve@virtuelvis.com) Received: from melkor (ti132110a080-0655.bb.online.no [80.212.210.143]) by hannibal.dreamhost.com (Postfix) with ESMTP id 96D42175260; Wed, 19 Jan 2005 08:49:45 -0800 (PST) To: "Eric Scheid" Cc: Atom-syntax Subject: Re: Revisiting feed discovery References: Message-ID: Date: Wed, 19 Jan 2005 17:49:42 +0100 From: "Arve Bersvendsen" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: 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 Thu, 20 Jan 2005 02:17:35 +1100, Eric Scheid wrote: >> b) Drop 'type' as a required attribute for link. Make it a 'MAY'. > > @type isn't a required attribute. In the Atom autodiscovery document I referred to, type is required: 4.2 type attribute The type attribute MUST be present in an Atom autodiscovery element. As defined in section 12.3 of HTML 4 [W3C.REC-html401-19991224], the value of the type attribute of any link element MUST be a registered Internet media type [RFC2045]. The media type for Atom is "application/atom+xml" (Atom Syndication Format 0.3), so in an Atom autodiscovery element the value of the type attribute MUST contain the string "application/atom+xml" in uppercase, lowercase, or mixed case. -- Arve http://virtuelvis.com From owner-atom-syntax@mail.imc.org Wed Jan 19 12:04: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 MAA28950 for ; Wed, 19 Jan 2005 12:04: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 j0JGkNIr089470; Wed, 19 Jan 2005 08: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 j0JGkNIb089469; Wed, 19 Jan 2005 08:46:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hannibal.dreamhost.com (postfix@hannibal.dreamhost.com [205.196.208.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0JGkN2o089459 for ; Wed, 19 Jan 2005 08:46:23 -0800 (PST) (envelope-from arve@virtuelvis.com) Received: from melkor (ti132110a080-0655.bb.online.no [80.212.210.143]) by hannibal.dreamhost.com (Postfix) with ESMTP id F1DA917515C for ; Wed, 19 Jan 2005 08:46:20 -0800 (PST) In-Reply-To: <1f2ed5cd0501190652773943ff@mail.gmail.com> References: <1f2ed5cd0501190652773943ff@mail.gmail.com> Subject: Re: Revisiting feed discovery To: Atom-syntax Message-ID: From: "Arve Bersvendsen" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Wed, 19 Jan 2005 17:46:17 +0100 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 Wed, 19 Jan 2005 15:52:22 +0100, Danny Ayers wrote: >> II) The MIME type may differ, depending on the client requesting it. > > Re. II) I'm not so sure about this, it depends somewhat on how you > interpret the element - I think an interpretation consistent with > webarch could be: there's data of this mime type available from this > URI (using a HTTP GET) That's in general not how hyperlinks/links are being treated on the web today. Apart from plugin content in /,RSS/Atom autodiscovery and linking to data that requires a specific mime-type (text/javascript and text/css), I don't think this is widely used. The common practice is "There's data here", and it is the job of the web server to negotiate data that is acceptable to the client. > Re. I) So? The publisher can simply update the link, as they'd have to > for various other changes. If someone follows a subscription link from web.archive.org, how can I change that? Or, if someone creates a blogroll, with links to feeds, how can they know the mime-type beforehand? Their User Agent may get (and prefer) application/rdf+xml, but that may not be consistent with what others' User Agents may understand or request. >> a) Change rel="alternate" to rel="feed", rel="subscription" or similar. > > On one (technical) level both make sense. However given that the > current version is pretty widely deployed, a) at least could be > counter-productive due to confusion. "alternate" might not be accurate > in a lot of cases, but as a simple convention is near enough. I know that established convention dictates that we can never use anything but "alternate", but this is overloading of the meaning of alternate - a mistake I fear we'll have to pay for somewhere down the road. >> b) Drop 'type' as a required attribute for link. Make it a 'MAY'. > > I don't > see much potential harm in b) but then again I don't see much benefit. > If the feed is available in multiple formats (at the same or different > URIs) then can't that be declared using multiple link elements? Which would bring the number of link elements on a page with four distinct feeds in three different formats up to twelve, but still only pointing at four documents? Isn't that overly redundant? >> [1] I also have a 'live' content-negotiated feed at >> that sends either >> application/rss+xml or application/atom+xml if a live experimental feed >> is >> wanted. > > Any thoughts on "application/rdf+xml"? Once I have an up and running RSS1.0 (1.1?) feed, it will be content-negotiated as well. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From owner-atom-syntax@mail.imc.org Wed Jan 19 20:18: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 UAA15943 for ; Wed, 19 Jan 2005 20:18: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 j0K0rlCS012241; Wed, 19 Jan 2005 16:53: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 j0K0rlGi012239; Wed, 19 Jan 2005 16:53: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 j0K0rjk4011361 for ; Wed, 19 Jan 2005 16:53: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); Thu, 20 Jan 2005 13:53:57 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 20 Jan 2005 11:53:09 +1100 Subject: Re: Revisiting feed discovery 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 20/1/05 3:49 AM, "Arve Bersvendsen" wrote: >>> b) Drop 'type' as a required attribute for link. Make it a 'MAY'. >> >> @type isn't a required attribute. > > In the Atom autodiscovery document I referred to, type is required: mea culpa > 4.2 type attribute > The type attribute MUST be present in an Atom autodiscovery element. > As defined in section 12.3 of HTML 4 [W3C.REC-html401-19991224], the > value of the type attribute of any link element MUST be a registered > Internet media type [RFC2045]. The media type for Atom is > "application/atom+xml" (Atom Syndication Format 0.3), so in an Atom > autodiscovery element the value of the type attribute MUST contain the > string "application/atom+xml" in uppercase, lowercase, or mixed case. hmmm ... doesn't say it's an "advisory" value only though. Assuming for the moment that it is, does this mean that I could use content negotiation on such a link, contrary to the "advisory" mime-type? e. From owner-atom-syntax@mail.imc.org Wed Jan 19 22: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 WAA24803 for ; Wed, 19 Jan 2005 22: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 j0K2si1s071285; Wed, 19 Jan 2005 18:54: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 j0K2siIo071279; Wed, 19 Jan 2005 18:54:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from outbound.mailhop.org (mailnull@outbound.mailhop.org [63.208.196.171]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0K2shKX071224 for ; Wed, 19 Jan 2005 18:54:44 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from 64-60-242-179.cust.telepacific.net ([64.60.242.179] helo=localhost) by outbound.mailhop.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CrST2-000DIt-V7 for atom-syntax@imc.org; Wed, 19 Jan 2005 21:54:41 -0500 Received: from ndw by localhost with local (Exim 4.34) id 1CrST1-0006oI-SX for atom-syntax@imc.org; Wed, 19 Jan 2005 18:54:39 -0800 To: Atom Syntax Subject: Re: AtomOWL & AtomIsRDF References: <44B27E00-689A-11D9-993A-000A95D9FA7A@bblfish.net> <87sm4y6zdr.fsf@nwalsh.com> <1f2ed5cd05011907336212af33@mail.gmail.com> From: Norman Walsh X-URL: http://nwalsh.com/ Date: Wed, 19 Jan 2005 18:54:39 -0800 In-Reply-To: <1f2ed5cd05011907336212af33@mail.gmail.com> (Danny Ayers's message of "Wed, 19 Jan 2005 16:33:55 +0100") Message-ID: <87u0pc24k0.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" X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 64.60.242.179 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: nwalsh Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Danny Ayers was heard to say: | I'd be interested to hear what you reckon to the mapping, in | particular the content stuff, I mentioned earlier in the thread- I'm sorry Danny, my attention has been mostly focussed elsewhere and I haven't really followed this thread. I want there to be a standard mapping, but I'm not too worried about what it is exactly. Be seeing you, norm =2D-=20 Norman Walsh | Simplicity is always a virtue.--Edward http://nwalsh.com/ | Abbey --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBB7x1vOyltUcwYWjsRAgskAJ9zvOXlzPJKH88CbTaUhyzRVGWScQCbBazh z7jKOqsbxL4+ZWHdZi2Cgk4= =/FAX -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Thu Jan 20 21:15: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 VAA07481 for ; Thu, 20 Jan 2005 21:15: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 j0L26bFL077427; Thu, 20 Jan 2005 18:06: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 j0L26bID077426; Thu, 20 Jan 2005 18:06:37 -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 j0L26bf8077402 for ; Thu, 20 Jan 2005 18:06:37 -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 <0IAN009TL9MEA7D0@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Fri, 21 Jan 2005 03:01:26 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IAN007QD9ZH4AK0@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Fri, 21 Jan 2005 03:09:17 +0100 (CET) Date: Fri, 21 Jan 2005 03:10:38 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: PaceExtensibilityAndVersioning In-reply-to: <41E80AF4.1020405@franklinmint.fm> To: Robert Sayre , Tim Bray 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: <41E80AF4.1020405@franklinmint.fm> 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, 14 Jan 2005 13:09:56 -0500, Robert Sayre wrote: >> I could live with this, but I think PaceMustUnderstandElement buys 80% >> of the benefit with 20% of the cost/apparatus. -Tim >> > -1. I suspect everyone else giving PaceMustUnderstand -1s will feel the > same. Yup. I've given mU -1 already, but just in case someone didn't see it: PaceMustUnderstand: -1. -- 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 Thu Jan 20 21:15: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 VAA07498 for ; Thu, 20 Jan 2005 21:15: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 j0L222jA075536; Thu, 20 Jan 2005 18:02: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 j0L2223r075535; Thu, 20 Jan 2005 18:02: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 j0L2203J075529 for ; Thu, 20 Jan 2005 18:02:01 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 20 Jan 2005 18:01:55 -0800 To: Atom WG From: Paul Hoffman / IMC Subject: Work Queue Rotation #15 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The following are dropped for lack of support: - PaceAltExtensibilityAndVersioning: one -1, no support from anyone. - PaceExtensibilityAndVersioning: one -0 and one -1. - PaccExtensibilityAndVersioningNoScenarios: one -0, no support from anyone. - PaceExtensionNamespace: two -1, no support from anyone. - PaceMinimalEntryVersioning: one +1, two -1s, and a 0-to--1.. - PaceMustUnderstandElement: a few positive responses, a bunch of very negative responses. - PaceSupersede: two -1s, no support from anyone. It's not all negative. PaceExtensionConstruct got a good bit of discussion and was heavily revised by its author in response. I think this has a good chance of being accepted after another round of discussion. That discussion should happen *soon* while we are still thinking about the extension mechanisms we want. Recycle with the new wording. Also, PaceExtendingAtom got one +1 from the author, but no other discussion. I think we should reconsider it as an addition after the stuff from PaceExtensionConstruct (if we accept that pace) or as all of section 9 (if we don't accept PaceExtensionConstruct); otherwise, we aren't helping folks who are thinking about extending Atom. Recycle. We're still making good progress, but there is more to be done. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Jan 20 21:16: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 VAA07539 for ; Thu, 20 Jan 2005 21:16: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 j0L29YpL078855; Thu, 20 Jan 2005 18:09: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 j0L29Ycl078854; Thu, 20 Jan 2005 18:09:34 -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 j0L29YAf078799 for ; Thu, 20 Jan 2005 18:09:34 -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 <0IAN009VN9REA3D0@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Fri, 21 Jan 2005 03:04:26 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IAN006VYA4HQU81@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Fri, 21 Jan 2005 03:12:18 +0100 (CET) Date: Fri, 21 Jan 2005 03:13:38 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: PaceMustUnderstandElement In-reply-to: <1268D6AA-6592-11D9-9616-000A95A51C9E@sun.com> To: 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: <1268D6AA-6592-11D9-9616-000A95A51C9E@sun.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 Thu, 13 Jan 2005 10:36:43 -0800, Tim Bray wrote: > The objections to this fall into two forms: > 1. We don't have prior art in the syndication space that proves this is > needed. > 2. This is someone else's problem, e.g. SOAP ...Or this isn't such a big problem at all. Let's not go there. -1. > And a decision to leave this out feels like hubris to me. "We're so > sure we got the core right that we can leave out an extremely cheap > potentially-valuable extension point." I doubt it. I don't think that's how it is. We all want Atom to be extensible in as many ways as possible. -- 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 Thu Jan 20 21: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 VAA07572 for ; Thu, 20 Jan 2005 21:17: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 j0L1u0hT071145; Thu, 20 Jan 2005 17:56: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 j0L1u0xO071143; Thu, 20 Jan 2005 17:56: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 j0L1tx6C070977 for ; Thu, 20 Jan 2005 17:56:00 -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 j0L1tbgY011922 for ; Fri, 21 Jan 2005 01:55:43 GMT Mime-Version: 1.0 (Apple Message framework v619) To: Atom WG Message-Id: <8C8A4206-6B4F-11D9-B353-000A95DC3D90@mac.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6--883679959; protocol="application/pkcs7-signature" From: Graham Subject: RSS to Atom migration Date: Fri, 21 Jan 2005 01:55:38 +0000 X-Mailer: Apple Mail (2.619) 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--883679959 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I don't know about anyone else but my hope for Atom is that soon after its release the whole RSS mess is left to sink into the sea. With this in mind, should we define a tag that can be put into RSS feeds so that client software can automatically switch over to the Atom version? I'd suggest reusing the link/alternate tag (in our namespace of course). Graham --Apple-Mail-6--883679959 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 9w0BCQUxDxcNMDUwMTIxMDE1NTM5WjAjBgkqhkiG9w0BCQQxFgQUyKDFoyAhzJh4MiLLQzlt4/rJ dq4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEArOeYCDRQKIhdgZsi0Tl8fw5u Bnsl22fyD81/v0pcoB6vaMHpN+679ATkK+SBI7zCQ9P4BQsBr4vQFzM4unpdde9aCo2BWW9zNOC3 8rnYqLJV4TqMEGn8JKbg/KU77DsqIL4YK3alj3PX7HDf13TvYZ+7QKqXL9AaAhc7IYov1Rjb4OV9 Jh32TOK+dAUaLVbuDQO/5sv6W06HrHvGvOVe+UZYYP9rsew+8hfAJ6nUYWpfZs1+tHY5JACFILva lubGKvUu1ZN24kxntJ9t+WLT3ZpP2ChsZEJkFg+ZJKk4ORizr88BMGNqCPFYUbMB4f8voJrvMyic vgeTsrPIYrvlAgAAAAAAAA== --Apple-Mail-6--883679959-- From owner-atom-syntax@mail.imc.org Thu Jan 20 21: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 VAA07596 for ; Thu, 20 Jan 2005 21:17: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 j0L23KU3076475; Thu, 20 Jan 2005 18:03: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 j0L23Kih076474; Thu, 20 Jan 2005 18:03:20 -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 j0L23H05076332 for ; Thu, 20 Jan 2005 18:03:18 -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 <0IAN009MD9GPADD0@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Fri, 21 Jan 2005 02:58:01 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IAN007AO9TS7ZG0@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Fri, 21 Jan 2005 03:05:52 +0100 (CET) Date: Fri, 21 Jan 2005 03:07:12 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: Revisiting feed discovery In-reply-to: To: Arve Bersvendsen Cc: atom-syntax@imc.org, Mark Pilgrim Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: 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 Wed, 19 Jan 2005 14:40:17 +0100, Arve Bersvendsen wrote: > a) rel="alternate" is a misnomer. Not all feeds are alternate content. > They may have some other relationship, such as rel="related". I agree. > b) Specifying a mime type for a feed is not always appropriate. If we > are assuming that "Cool URIs don't change", requiring a type-attribute > is a huge mistake: > I) The MIME type of the feed may change over time. Feeds may migrate > from being application/rss+xml to being application/atom+xml > II) The MIME type may differ, depending on the client requesting it. I agree with both points. > a) Change rel="alternate" to rel="feed", rel="subscription" or similar. What I have a problem with is «what is the feed for if it isn't an alternative to the resource you're looking at?». 'rel' should say what relation the current resource has to the referenced one. «Feed» isn't a relation, «alternate» is. Not sure if the semantics are very important here, but I'm having trouble with putting a non-relative word like «feed» into an attribute which is supposed to describe relationship. > b) Drop 'type' as a required attribute for link. Make it a 'MAY'. +1. -- 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 Thu Jan 20 21:34: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 VAA08312 for ; Thu, 20 Jan 2005 21:34: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 j0L2QacO097837; Thu, 20 Jan 2005 18:26: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 j0L2Qa1M097836; Thu, 20 Jan 2005 18:26:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hannibal.dreamhost.com (postfix@hannibal.dreamhost.com [205.196.208.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0L2QaoX097811 for ; Thu, 20 Jan 2005 18:26:36 -0800 (PST) (envelope-from arve@virtuelvis.com) Received: from melkor (ti132110a080-0005.bb.online.no [80.212.208.5]) by hannibal.dreamhost.com (Postfix) with ESMTP id 3DC44175215; Thu, 20 Jan 2005 18:26:32 -0800 (PST) Date: Fri, 21 Jan 2005 03:26:27 +0100 To: Graham Subject: Re: RSS to Atom migration References: <8C8A4206-6B4F-11D9-B353-000A95DC3D90@mac.com> Cc: Atom-syntax From: "Arve Bersvendsen" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <8C8A4206-6B4F-11D9-B353-000A95DC3D90@mac.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, 21 Jan 2005 01:55:38 +0000, Graham wrote: > I don't know about anyone else but my hope for Atom is that soon after > its release the whole RSS mess is left to sink into the sea. With this > in mind, should we define a tag that can be put into RSS feeds so that > client software can automatically switch over to the Atom version? I'd > suggest reusing the link/alternate tag (in our namespace of course). I'd rather suggest using looking at section 14.1 of HTTP. Serve feeds using content-negotiation, and set q values so that Atom-enabled software will get Atom feeds. (Having said that, it seems like aggregator authors, apart from a select few don't care about what HTTP is. I'm currently considering blocking bloglines because they fail to respect HTTP 301 responses) -- Arve Bersvendsen From owner-atom-syntax@mail.imc.org Thu Jan 20 21: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 VAA08982 for ; Thu, 20 Jan 2005 21: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 j0L2dECh014886; Thu, 20 Jan 2005 18:39: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 j0L2dE8P014884; Thu, 20 Jan 2005 18:39:14 -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 j0L2dCC3014834 for ; Thu, 20 Jan 2005 18:39:13 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 20 Jan 2005 18:39:11 -0800 To: Atom WG From: Paul Hoffman / IMC Subject: Pro-forma request about whether we should meet at the next IETF Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi again. The next IETF meeting is in Minneapolis, March 6-11; see for details. This WG has not met at an IETF before, and it seems to be doing fine without a face-to-face meeting, but as co-chair, I should ask: do people think we should meet? If so, say so now because we need to get our slot request in soon. I'm kinda assuming we won't meet, but you never know... --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri Jan 21 01:47: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 BAA24684 for ; Fri, 21 Jan 2005 01:47: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 j0L6Zj4Y005371; Thu, 20 Jan 2005 22:35: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 j0L6ZjIn005370; Thu, 20 Jan 2005 22:35:45 -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 j0L6ZiTN005027 for ; Thu, 20 Jan 2005 22:35:44 -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, 21 Jan 2005 19:35:54 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 21 Jan 2005 17:35:05 +1100 Subject: Re: Revisiting feed discovery 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 j0L6ZjTN005360 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 21/1/05 1:07 PM, "Asbjørn Ulsberg" wrote: >> a) Change rel="alternate" to rel="feed", rel="subscription" or similar. > > What I have a problem with is «what is the feed for if it isn't an > alternative to the resource you're looking at?». How is a resource which shows the last 15 entries as of today an "alternative" representation of an entry which was published six months ago and has long slipped out of the sliding window? > 'rel' should say what > relation the current resource has to the referenced one. «Feed» isn't a > relation, «alternate» is. my interpretation of "feed" as a relationship is "here is the feed in which this entry was originally published". I prefer "feed", it's shorter. > Not sure if the semantics are very important here, but I'm having trouble > with putting a non-relative word like «feed» into an attribute which is > supposed to describe relationship. Its not the best word, but others which are better are already taken for other purposes (eg "source", "origin", etc), or are clumsy word-pairs which are still not properly indicative of the ongoing publishing nature (eg. DC's "part-of"). e. From owner-atom-syntax@mail.imc.org Fri Jan 21 06:15: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 GAA28910 for ; Fri, 21 Jan 2005 06:15: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 j0LAttRY079148; Fri, 21 Jan 2005 02: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 j0LAttdQ079147; Fri, 21 Jan 2005 02:55:55 -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 j0LAttYk079094 for ; Fri, 21 Jan 2005 02:55:55 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so129113rnz for ; Fri, 21 Jan 2005 02:55: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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=LGizDKD0jh57074y79Fw2jq4JBRR1PvdqmwEGvLcxX6yL/fxl0WeEx5eAkNjLUhSmvdhGH0kc+98FjXSbNVr0FwSkU8710mGZTQZhXy6cWYRrLGox2yxRMdjFldgMxlom0c/WdjV1cW/a61h2zyhA2ksE0Y0aeVJ8InwYkTFGDo= Received: by 10.38.8.49 with SMTP id 49mr152349rnh; Fri, 21 Jan 2005 02:55:47 -0800 (PST) Received: by 10.38.179.71 with HTTP; Fri, 21 Jan 2005 02:55:47 -0800 (PST) Message-ID: <1f2ed5cd0501210255524a5bc0@mail.gmail.com> Date: Fri, 21 Jan 2005 11:55:47 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Paul Hoffman / IMC Subject: Re: Work Queue Rotation #15 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 Thu, 20 Jan 2005 18:01:55 -0800, Paul Hoffman / IMC wrote: > > The following are dropped for lack of support: No objections there - I, and probably others abstained from commenting on this batch, as the new proposals were in the pipeline. > It's not all negative. PaceExtensionConstruct got a good bit of > discussion and was heavily revised by its author in response. I think > this has a good chance of being accepted after another round of > discussion. That discussion should happen *soon* while we are still > thinking about the extension mechanisms we want. Recycle with the new > wording. Yep. I expect Henry's AtomAsRDF/AtomOWL will have been refactored too, I would think it appropriate to include that/those in the same round. (If I get this last doc rewrite finished this morning, I might even have chance to look at this stuff properly myself ;-) Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Jan 21 22: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 WAA18288 for ; Fri, 21 Jan 2005 22: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 j0M30S20080871; Fri, 21 Jan 2005 19:00: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 j0M30Sel080870; Fri, 21 Jan 2005 19:00: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-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 j0M30Rhv080842 for ; Fri, 21 Jan 2005 19:00:27 -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 j0M30Rdt018688 for ; Fri, 21 Jan 2005 20:00:27 -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 <0IAP008BK70QPZ@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 21 Jan 2005 20:00:26 -0700 (MST) Received: from [10.242.56.121] ([208.54.34.36]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAP000SZ70P8A@mail.sun.net> for atom-syntax@imc.org; Fri, 21 Jan 2005 20:00:26 -0700 (MST) Date: Fri, 21 Jan 2005 18:57:05 -0800 From: Tim Bray Subject: AtomAsRDF To: Atom Syntax Message-id: <4C9DF8A2-6C21-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 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT I just read this, and it's moving toward being a usable Pace, but it isn't one yet. Could Henry or someone please update it so it has *specific* suggestions for language changes to the draft, then we can see if it gets consensus support. -Tim From owner-atom-syntax@mail.imc.org Fri Jan 21 22: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 WAA18855 for ; Fri, 21 Jan 2005 22: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 j0M3W2Ih091324; Fri, 21 Jan 2005 19:32: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 j0M3W2hc091323; Fri, 21 Jan 2005 19:32: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 j0M3W1L4091311 for ; Fri, 21 Jan 2005 19:32:01 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.102]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CsC0D-00074T-ET; Sat, 22 Jan 2005 03:31:57 +0000 Message-ID: <41F1C929.9070305@franklinmint.fm> Date: Fri, 21 Jan 2005 22:31:53 -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: AtomAsRDF References: <4C9DF8A2-6C21-11D9-9797-000A95A51C9E@sun.com> In-Reply-To: <4C9DF8A2-6C21-11D9-9797-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: > > I just read this, and it's moving toward being a usable Pace, but it > isn't one yet. Could Henry or someone please update it so it has > *specific* suggestions for language changes to the draft, then we can > see if it gets consensus support. > I agree, but one point mentioned there is bothering me. "Atom attributes are not in the atom namespace. It is deprecated in rdf for this to be the case. (so I suppose this means it is still possible)." What course of action can we take with that? Robert Sayre From owner-atom-syntax@mail.imc.org Sat Jan 22 07: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 HAA00676 for ; Sat, 22 Jan 2005 07: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 j0MCVTON026531; Sat, 22 Jan 2005 04:31: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 j0MCVTxt026530; Sat, 22 Jan 2005 04:31: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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0MCVQAR026480 for ; Sat, 22 Jan 2005 04:31:27 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so16080rnz for ; Sat, 22 Jan 2005 04:31: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=uqTBoXup3+plJDbyS6do4heh0WtoHOjLyyEJJ3XAvmGSRjUpm4Ag9l72Zb6CncSaVFQaeULfA6sFBbdR6nRoSl4t2Spj/C9NV1ygZ+JEh6zVkuE63Pige5POPY/SG/fL2TBvawmbDh1K7pj7D3gbrqAb0rlww/tQ8DsttX/12AI= Received: by 10.38.8.12 with SMTP id 12mr26625rnh; Sat, 22 Jan 2005 04:31:20 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sat, 22 Jan 2005 04:31:20 -0800 (PST) Message-ID: <1f2ed5cd0501220431605acde3@mail.gmail.com> Date: Sat, 22 Jan 2005 13:31:20 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Robert Sayre Subject: Re: AtomAsRDF Cc: Tim Bray , Atom Syntax In-Reply-To: <41F1C929.9070305@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4C9DF8A2-6C21-11D9-9797-000A95A51C9E@sun.com> <41F1C929.9070305@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 21 Jan 2005 22:31:53 -0500, Robert Sayre wrote: > > Tim Bray wrote: > > > > I just read this, and it's moving toward being a usable Pace, but it > > isn't one yet. Could Henry or someone please update it so it has > > *specific* suggestions for language changes to the draft, then we can > > see if it gets consensus support. Yep, maybe even put Pace in the title just for convention's sake. > "Atom attributes are not in the atom namespace. It is deprecated in rdf > for this to be the case. (so I suppose this means it is still possible)." > > What course of action can we take with that? My guess is there's no will to namespace-qualify all the core attributes. So I reckon the easiest course would be say that each of the attributes has a namespace-qualified shadow with the same meaning. When expressed as an RDF vocabulary, Atom will use these attributes. Whether or not general Atom users should have the option to use these is another question (probably best avoided in this context). Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Jan 22 09:37: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 JAA06641 for ; Sat, 22 Jan 2005 09:37: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 j0MEP5Li007552; Sat, 22 Jan 2005 06:25: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 j0MEP5k6007551; Sat, 22 Jan 2005 06:25:05 -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 j0MEP4mp007536 for ; Sat, 22 Jan 2005 06:25:05 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 84413 messnum 3856407 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 22 Jan 2005 14:24:58 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.150?) (83.70.164.213) by mail08.svc.cra.dublin.eircom.net (qp 84413) with SMTP; 22 Jan 2005 14:24:58 -0000 Message-ID: <41F26238.9080907@dehora.net> Date: Sat, 22 Jan 2005 14:24:56 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Tim Bray , Atom Syntax Subject: Re: AtomAsRDF References: <4C9DF8A2-6C21-11D9-9797-000A95A51C9E@sun.com> <41F1C929.9070305@franklinmint.fm> In-Reply-To: <41F1C929.9070305@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: > > Tim Bray wrote: > >> >> I just read this, and it's moving toward being a usable Pace, but it >> isn't one yet. Could Henry or someone please update it so it has >> *specific* suggestions for language changes to the draft, then we can >> see if it gets consensus support. > > > I agree, but one point mentioned there is bothering me. > > "Atom attributes are not in the atom namespace. It is deprecated in rdf > for this to be the case. (so I suppose this means it is still possible)." > > What course of action can we take with that? 1. specify that processors should interpret unprefixed attributes in atom namespaced elements to be in the atom namespace. This is idiom as specification. 2. specify that all our attributes are to be prefixed. This is specification as overkill. 3. mutter darkly about that damnable namespaces spec, and do nothing :) I've seen heated arguments over 1 and 2. The argument for 1 is that you only need prefixes for cases where you're dropping attributes into other people's elements, for your own elements prefixes are effectively redundant. The argument for 2 is based on the fact that there's a hole in the ns spec, screw idiom or effective redundancy. RDF requires XML artefacts are mapped onto URIs; it's much easier to do that if you know what the full QNames are to begin with. My preference is for 2. cheers Bill From owner-atom-syntax@mail.imc.org Sat Jan 22 13:31: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 NAA22682 for ; Sat, 22 Jan 2005 13:31: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 j0MIGgf1022778; Sat, 22 Jan 2005 10:17: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 j0MIBvNG021472; Sat, 22 Jan 2005 10:11:57 -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 j0MIBBld021252 for ; Sat, 22 Jan 2005 10:11:19 -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 j0MIB0Vu014671 for ; Sat, 22 Jan 2005 11:11: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 <0IAQ0082HD6BPZ@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 22 Jan 2005 11:11:00 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAQ0003BD687R@mail.sun.net> for atom-syntax@imc.org; Sat, 22 Jan 2005 11:10:59 -0700 (MST) Date: Sat, 22 Jan 2005 10:07:36 -0800 From: Tim Bray Subject: Re: AtomAsRDF In-reply-to: <41F26238.9080907@dehora.net> To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Cc: Atom Syntax , Robert Sayre Message-id: <7EF03B50-6CA0-11D9-9797-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=ISO-8859-1; format=flowed References: <4C9DF8A2-6C21-11D9-9797-000A95A51C9E@sun.com> <41F1C929.9070305@franklinmint.fm> <41F26238.9080907@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0MIBMld021338 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Jan 22, 2005, at 6:24 AM, Bill de hÓra wrote: > 1. specify that processors should interpret unprefixed attributes in > atom namespaced elements to be in the atom namespace. This is idiom as > specification. > > 2. specify that all our attributes are to be prefixed. This is > specification as overkill. > > 3. mutter darkly about that damnable namespaces spec, and do nothing :) > My preference is for 2. Blecch. As in, ugly and wasteful. -Tim From owner-atom-syntax@mail.imc.org Sat Jan 22 13: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 NAA22704 for ; Sat, 22 Jan 2005 13:31: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 j0MI5fJa019713; Sat, 22 Jan 2005 10:05: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 j0MI5fg0019712; Sat, 22 Jan 2005 10:05: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.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0MI5eMF019706 for ; Sat, 22 Jan 2005 10:05:40 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so25559rnz for ; Sat, 22 Jan 2005 10:05:40 -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=rnaJPErtviymuVMc/4vnhhuwCRwXBfucAYsUC8sscnghEslyEQoLfAUBDA8+B3AhHq5y/K/M4Irv0vyVE7kyZJChcXOgkTrBAHJh5viuZuFgfE97sFfAts57kJtO3TPdBouPlxa4pc+/oJk6PwRr2BWlAxo/1wS26MfbhNPQ8Ak= Received: by 10.38.8.49 with SMTP id 49mr102234rnh; Sat, 22 Jan 2005 10:05:40 -0800 (PST) Received: by 10.38.179.71 with HTTP; Sat, 22 Jan 2005 10:05:39 -0800 (PST) Message-ID: <1f2ed5cd0501221005a9d7008@mail.gmail.com> Date: Sat, 22 Jan 2005 19:05:39 +0100 From: Danny Ayers Reply-To: Danny Ayers To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: AtomAsRDF Cc: Robert Sayre , Tim Bray , Atom Syntax In-Reply-To: <41F26238.9080907@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <4C9DF8A2-6C21-11D9-9797-000A95A51C9E@sun.com> <41F1C929.9070305@franklinmint.fm> <41F26238.9080907@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0MI5fMF019707 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sat, 22 Jan 2005 14:24:56 +0000, Bill de hÓra wrote: > 1. specify that processors should interpret unprefixed attributes in > atom namespaced elements to be in the atom namespace. This is idiom as > specification. > > 2. specify that all our attributes are to be prefixed. This is > specification as overkill. > > 3. mutter darkly about that damnable namespaces spec, and do nothing :) > My preference is for 2. Ah, perhaps I was second-guessing about that being unlikely to get support. Personally I'd prefer 2 as well, after having recently experienced confusion over no-namespace attributes (after having worked with XML plenty long enough that I should have known better ;-). Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Jan 22 13:40: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 NAA23110 for ; Sat, 22 Jan 2005 13:40: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 j0MIVKRl036040; Sat, 22 Jan 2005 10:31: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 j0MIVKpx036039; Sat, 22 Jan 2005 10:31: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 j0MIVJI8035826 for ; Sat, 22 Jan 2005 10:31:19 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 15836 invoked by uid 17064); 22 Jan 2005 18:31:11 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.251.47.146]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 22 Jan 2005 18:31:11 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <7EF03B50-6CA0-11D9-9797-000A95A51C9E@sun.com> References: <4C9DF8A2-6C21-11D9-9797-000A95A51C9E@sun.com> <41F1C929.9070305@franklinmint.fm> <41F26238.9080907@dehora.net> <7EF03B50-6CA0-11D9-9797-000A95A51C9E@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: From: Henry Story Subject: Re: AtomAsRDF Date: Sat, 22 Jan 2005 19:31:12 +0100 To: Atom WG X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0MIVJI8036030 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I'll put all solutions up on the Pace when I get time. I think 1. is good enough myself. I imagine that perhaps a future version of XML will by default put non namespaced attributes in the default namespace, no? In which case things will work out ok in the long term. If there are any other solutions, we should add them to the list. Henry On 22 Jan 2005, at 19:07, Tim Bray wrote: > > On Jan 22, 2005, at 6:24 AM, Bill de hÓra wrote: > >> 1. specify that processors should interpret unprefixed attributes in >> atom namespaced elements to be in the atom namespace. This is idiom >> as specification. >> >> 2. specify that all our attributes are to be prefixed. This is >> specification as overkill. >> >> 3. mutter darkly about that damnable namespaces spec, and do nothing >> :) > >> My preference is for 2. > > Blecch. As in, ugly and wasteful. -Tim > From owner-atom-syntax@mail.imc.org Sat Jan 22 13: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 NAA23888 for ; Sat, 22 Jan 2005 13:51: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 j0MIeLUJ043302; Sat, 22 Jan 2005 10:40: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 j0MIeLfN043301; Sat, 22 Jan 2005 10:40:21 -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 j0MIeKXR043282 for ; Sat, 22 Jan 2005 10:40:21 -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 j0MIcsZ2005715; Sat, 22 Jan 2005 18:39:00 GMT In-Reply-To: <41F26238.9080907@dehora.net> References: <4C9DF8A2-6C21-11D9-9797-000A95A51C9E@sun.com> <41F1C929.9070305@franklinmint.fm> <41F26238.9080907@dehora.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9--737083254; protocol="application/pkcs7-signature" Message-Id: Cc: Atom Syntax From: Graham Subject: Re: AtomAsRDF Date: Sat, 22 Jan 2005 18:38:55 +0000 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= X-Mailer: Apple Mail (2.619) 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--737083254 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 22 Jan 2005, at 2:24 pm, Bill de h=D3ra wrote: > 1. specify that processors should interpret unprefixed attributes in=20= > atom namespaced elements to be in the atom namespace. This is idiom as=20= > specification. This would only be required for mapping to RDF? It wouldn't effect=20 other processors? > 2. specify that all our attributes are to be prefixed. This is=20 > specification as overkill. Nyet. > 3. mutter darkly about that damnable namespaces spec, and do nothing = :) OK. Graham= --Apple-Mail-9--737083254 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 9w0BCQUxDxcNMDUwMTIyMTgzODU1WjAjBgkqhkiG9w0BCQQxFgQUcDseHcRSe52r1/cN2td3HSUU wgkweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAtm1KKQACYVyf2T5mpEkZ0Reh fELV8Mmk3dSYLsgejbtg3oCHkQZUmhLy3Lk4Lt1VFre+GaJ7vR9G2GVnbdTqfubd6DeNO+HkAK+U lGzSvw+oaEMB/j+k7/88xrvU8oID03EIfrYccBB4c7DjiUBzVJUEg6J7QJe2KiDhYndQwcjkCwQE k4n4ymRWeTx26lXi3PMApkhO+rfwJqEXytYaXdxzaMZSlGgPEJF+fJ89chGpNp2o788c7y//2xzg xtfHIPMw9ayUi/MREuDIiVsXuD9QAMh+Iyh6oBoiE4XaSTSElcNa5lzwA+LqrvaIAwgH+u02nrAv dg7d2DnCz6lmWAAAAAAAAA== --Apple-Mail-9--737083254-- From owner-atom-syntax@mail.imc.org Sat Jan 22 14:01: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 OAA24658 for ; Sat, 22 Jan 2005 14:01: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 j0MIreGn061026; Sat, 22 Jan 2005 10:53: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 j0MIredN061025; Sat, 22 Jan 2005 10:53: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 j0MIrdrF061018 for ; Sat, 22 Jan 2005 10:53: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 j0MIrZVu025781 for ; Sat, 22 Jan 2005 11:53:35 -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 <0IAQ009COF5B6L@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 22 Jan 2005 11:53:35 -0700 (MST) Received: from [192.168.1.17] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAQ000ZWF5A8A@mail.sun.net> for atom-syntax@imc.org; Sat, 22 Jan 2005 11:53:35 -0700 (MST) Date: Sat, 22 Jan 2005 10:50:13 -0800 From: Tim Bray Subject: Re: AtomAsRDF In-reply-to: To: Henry Story Cc: Atom WG Message-id: <72F1C4A1-6CA6-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: <4C9DF8A2-6C21-11D9-9797-000A95A51C9E@sun.com> <41F1C929.9070305@franklinmint.fm> <41F26238.9080907@dehora.net> <7EF03B50-6CA0-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 22, 2005, at 10:31 AM, Henry Story wrote: > I'll put all solutions up on the Pace when I get time. Then you need multiple different Paces. A Pace isn't real unless it makes a specific suggestion along the lines of "add/replace this language". > I think 1. is good enough myself. I imagine that perhaps a future > version of XML will by default put non namespaced attributes in the > default namespace, no? In which case things will work out ok in the > long term. There is zero chance of that happening. Whether or not you like the current behavior (a majority, but not everybody, dislikes it), we're stuck with it. -Tim From owner-atom-syntax@mail.imc.org Sat Jan 22 19:36: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 TAA12988 for ; Sat, 22 Jan 2005 19:36: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 j0N0EwRG048222; Sat, 22 Jan 2005 16: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 j0N0Ew9I048221; Sat, 22 Jan 2005 16:14:58 -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 j0N0EuTK047944 for ; Sat, 22 Jan 2005 16:14:57 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 19672 messnum 5051745 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 23 Jan 2005 00:06:58 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.150?) (83.70.164.213) by mail04.svc.cra.dublin.eircom.net (qp 19672) with SMTP; 23 Jan 2005 00:06:58 -0000 Message-ID: <41F2EAA1.1030102@dehora.net> Date: Sun, 23 Jan 2005 00:06: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: Tim Bray CC: Atom Syntax , Robert Sayre Subject: Re: AtomAsRDF References: <4C9DF8A2-6C21-11D9-9797-000A95A51C9E@sun.com> <41F1C929.9070305@franklinmint.fm> <41F26238.9080907@dehora.net> <7EF03B50-6CA0-11D9-9797-000A95A51C9E@sun.com> In-Reply-To: <7EF03B50-6CA0-11D9-9797-000A95A51C9E@sun.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 Tim Bray wrote: > On Jan 22, 2005, at 6:24 AM, Bill de hÓra wrote: > >> 1. specify that processors should interpret unprefixed attributes in >> atom namespaced elements to be in the atom namespace. This is idiom as >> specification. >> >> 2. specify that all our attributes are to be prefixed. This is >> specification as overkill. >> >> 3. mutter darkly about that damnable namespaces spec, and do nothing :) > > >> My preference is for 2. > > > Blecch. As in, ugly and wasteful. -Tim I feel the same way. Did you have a robust suggestion? cheers Bill From owner-atom-syntax@mail.imc.org Mon Jan 24 00:11: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 AAA17647 for ; Mon, 24 Jan 2005 00:11: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 j0O4OxK6055209; Sun, 23 Jan 2005 20: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 j0O4OxUh055208; Sun, 23 Jan 2005 20:24:59 -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 j0O4Ou18055172 for ; Sun, 23 Jan 2005 20:24: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 3234D4F001; Sun, 23 Jan 2005 23:24:48 -0500 (EST) Message-Id: <6.0.0.20.2.20050124121120.07392888@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 24 Jan 2005 12:12:50 +0900 To: Tim Bray , Bill de =?ISO-2022-JP?B?aBskQiViGyhCcmE=?= From: Martin Duerst Subject: Re: AtomAsRDF Cc: Atom Syntax , Robert Sayre In-Reply-To: <7EF03B50-6CA0-11D9-9797-000A95A51C9E@sun.com> References: <4C9DF8A2-6C21-11D9-9797-000A95A51C9E@sun.com> <41F1C929.9070305@franklinmint.fm> <41F26238.9080907@dehora.net> <7EF03B50-6CA0-11D9-9797-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; 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 03:07 05/01/23, Tim Bray wrote: > >On Jan 22, 2005, at 6:24 AM, Bill de h$B%b(Bra wrote: > >> 1. specify that processors should interpret unprefixed attributes in atom namespaced elements to be in the atom namespace. This is idiom as specification. >> >> 2. specify that all our attributes are to be prefixed. This is specification as overkill. >> >> 3. mutter darkly about that damnable namespaces spec, and do nothing :) > >> My preference is for 2. > >Blecch. As in, ugly and wasteful. -Tim My preference is for 1, too. After all, we are doing "Atom as RDF", not "Atom is RDF", here, in which case 1 is all we need, and it's definitely easier for people not involved in RDF. Regards, Martin. From owner-atom-syntax@mail.imc.org Mon Jan 24 04:25: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 EAA20751 for ; Mon, 24 Jan 2005 04:25: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 j0O99xGk069397; Mon, 24 Jan 2005 01:09: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 j0O99xHW069396; Mon, 24 Jan 2005 01:09: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 j0O99vT7069361 for ; Mon, 24 Jan 2005 01:09:58 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 15980 invoked by uid 17064); 24 Jan 2005 09:03:13 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.251.47.134]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 24 Jan 2005 09:03:13 -0000 In-Reply-To: <6.0.0.20.2.20050124121120.07392888@localhost> References: <4C9DF8A2-6C21-11D9-9797-000A95A51C9E@sun.com> <41F1C929.9070305@franklinmint.fm> <41F26238.9080907@dehora.net> <7EF03B50-6CA0-11D9-9797-000A95A51C9E@sun.com> <6.0.0.20.2.20050124121120.07392888@localhost> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=HZ-GB-2312; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax , Robert Sayre , Tim Bray , =?ISO-2022-JP?B?QmlsbCBkZSBoGyRCJWIbKEJyYQ==?= From: Henry Story Subject: Re: AtomAsRDF Date: Mon, 24 Jan 2005 10:02:49 +0100 To: Martin Duerst X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I agree with Martin D~{(9~}rst's analysis. I have added the following to the AtomAsRDF [1] proposal. Text close to the following should appear in the spec (please make more precise) "Processors should interpret unprefixed attributes in atom namespaced elements to be in the atom namespace" This seems good enough for what we need, and should cause absolutely no difficulty for non-rdf aware parsers. There is a section "Rejected Solutions" which mentions solution 2. This is to help people coming to the discussion get an overview of how we came to our decision, and perhaps notice an oversight. Henry Story http://bblfish.net/blog/ [1] http://www.intertwingly.net/wiki/pie/AtomAsRDF On 24 Jan 2005, at 04:12, Martin Duerst wrote: > > At 03:07 05/01/23, Tim Bray wrote: > > > >On Jan 22, 2005, at 6:24 AM, Bill de h~{%b~}ra wrote: > > > >> 1. specify that processors should interpret unprefixed attributes > in atom namespaced elements to be in the atom namespace. This is idiom > as specification. > >> > >> 2. specify that all our attributes are to be prefixed. This is > specification as overkill. > >> > >> 3. mutter darkly about that damnable namespaces spec, and do > nothing :) > > > >> My preference is for 2. > > > >Blecch. As in, ugly and wasteful. -Tim > > My preference is for 1, too. After all, we are doing "Atom as RDF", > not "Atom is RDF", here, in which case 1 is all we need, and it's > definitely easier for people not involved in RDF. > > Regards, Martin. From owner-atom-syntax@mail.imc.org Mon Jan 24 12: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 MAA02870 for ; Mon, 24 Jan 2005 12:18: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 j0OGdDnW067108; Mon, 24 Jan 2005 08:39: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 j0OGdCoq067107; Mon, 24 Jan 2005 08:39: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 j0OGcuSP067090 for ; Mon, 24 Jan 2005 08:38:57 -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 j0OGcudt013237 for ; Mon, 24 Jan 2005 09:38:56 -0700 (MST) Received: from xpa-fe1 (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 <0IAT00L57Y8VH5@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 09:38:56 -0700 (MST) Received: from [192.168.1.15] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAT00E0NY8U60@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 09:38:55 -0700 (MST) Date: Mon, 24 Jan 2005 08:35:37 -0800 From: Tim Bray Subject: Re: AtomAsRDF In-reply-to: To: Henry Story Cc: Atom Syntax , Robert Sayre , =?ISO-2022-JP?B?QmlsbCBkZSBoGyRCJWIbKEJyYQ==?= , Martin Duerst 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: <4C9DF8A2-6C21-11D9-9797-000A95A51C9E@sun.com> <41F1C929.9070305@franklinmint.fm> <41F26238.9080907@dehora.net> <7EF03B50-6CA0-11D9-9797-000A95A51C9E@sun.com> <6.0.0.20.2.20050124121120.07392888@localhost> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 24, 2005, at 1:02 AM, Henry Story wrote: > Text close to the following should appear in the spec (please make > more precise) > "Processors should interpret unprefixed attributes in atom namespaced > elements to be in the atom namespace" Who are you asking to make it more precise? -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 12:31: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 MAA03952 for ; Mon, 24 Jan 2005 12:31: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 j0OH2WSP068602; Mon, 24 Jan 2005 09:02: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 j0OH2WQp068601; Mon, 24 Jan 2005 09:02:32 -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 j0OH2WFg068583 for ; Mon, 24 Jan 2005 09:02:32 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 8619 invoked by uid 17064); 24 Jan 2005 17:02:21 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.251.47.154]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 24 Jan 2005 17:02:21 -0000 In-Reply-To: References: <4C9DF8A2-6C21-11D9-9797-000A95A51C9E@sun.com> <41F1C929.9070305@franklinmint.fm> <41F26238.9080907@dehora.net> <7EF03B50-6CA0-11D9-9797-000A95A51C9E@sun.com> <6.0.0.20.2.20050124121120.07392888@localhost> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax , Robert Sayre , =?ISO-8859-1?Q?Bill_de_h=D3ra?= , =?ISO-8859-1?Q?Martin_D=FCrst?= From: Henry Story Subject: Re: AtomAsRDF Date: Mon, 24 Jan 2005 18:01:58 +0100 To: Tim Bray X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 24 Jan 2005, at 17:35, Tim Bray wrote: > On Jan 24, 2005, at 1:02 AM, Henry Story wrote: > >> Text close to the following should appear in the spec (please make >> more precise) >> "Processors should interpret unprefixed attributes in atom >> namespaced elements to be in the atom namespace" > > Who are you asking to make it more precise? -Tim whoever knows for example where it would be best placed in the spec, if it should replace some other sentence, if SHOULD should be capitalized, ... These are the kind of problems I think we are left with now on this issue. Perhaps they can be left until later whilst we deal with other similar sized problems. I believe one should leave the end game moves to the endgame and not try to work out details before the time is ready for them. Anyway that is what I learnt playing Go [1], and it seems to apply to all kinds of areas. Henry [1] http://en.wikipedia.org/wiki/Go_%28board_game%29 From owner-atom-syntax@mail.imc.org Mon Jan 24 12:53: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 MAA06025 for ; Mon, 24 Jan 2005 12:53: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 j0OHOBH3070565; Mon, 24 Jan 2005 09:24: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 j0OHOB0P070564; Mon, 24 Jan 2005 09:24: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-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 j0OHOAkn070557 for ; Mon, 24 Jan 2005 09:24:10 -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 j0OHOAVu009377 for ; Mon, 24 Jan 2005 10:24:10 -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 <0IAU000EP0C44V@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 10:24:05 -0700 (MST) Received: from [192.168.1.15] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU007X10BXOK@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 10:23:58 -0700 (MST) Date: Mon, 24 Jan 2005 09:20:40 -0800 From: Tim Bray Subject: Re: AtomAsRDF In-reply-to: To: Henry Story Cc: Atom Syntax , Robert Sayre , =?ISO-8859-1?Q?Bill_de_h=D3ra?= , =?ISO-8859-1?Q?Martin_D=FCrst?= Message-id: <453241F9-6E2C-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: <4C9DF8A2-6C21-11D9-9797-000A95A51C9E@sun.com> <41F1C929.9070305@franklinmint.fm> <41F26238.9080907@dehora.net> <7EF03B50-6CA0-11D9-9797-000A95A51C9E@sun.com> <6.0.0.20.2.20050124121120.07392888@localhost> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 24, 2005, at 9:01 AM, Henry Story wrote: >>> Text close to the following should appear in the spec (please make >>> more precise) >>> ... >> Who are you asking to make it more precise? -Tim > > whoever knows for example where it would be best placed in the spec, > if it should replace some other sentence, if SHOULD should be > capitalized, ... You don't understand. The only reality is the actual text in the spec. Nothing else exists. Until there is an actual proposal for THE ACTUAL WORDS that are going into the spec, there is nothing. The reason is that after this WG goes away (which it will), the only communication between us and the future is the content of the specification. It is the only subject on which we can have a meaningful debate. Serious discussion of this subject will not start until there is an actual proposal placed before the WG. --Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 15:16: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 PAA19315 for ; Mon, 24 Jan 2005 15:16: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 j0OJjWZL081151; Mon, 24 Jan 2005 11:45: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 j0OJjW2p081150; Mon, 24 Jan 2005 11:45:32 -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 j0OJjVwC081144 for ; Mon, 24 Jan 2005 11:45:31 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 29449 invoked by uid 17064); 24 Jan 2005 19:45:31 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.251.47.228]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 24 Jan 2005 19:45:31 -0000 In-Reply-To: <453241F9-6E2C-11D9-9797-000A95A51C9E@sun.com> References: <4C9DF8A2-6C21-11D9-9797-000A95A51C9E@sun.com> <41F1C929.9070305@franklinmint.fm> <41F26238.9080907@dehora.net> <7EF03B50-6CA0-11D9-9797-000A95A51C9E@sun.com> <6.0.0.20.2.20050124121120.07392888@localhost> <453241F9-6E2C-11D9-9797-000A95A51C9E@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <81D98645-6E40-11D9-91F1-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax , Robert Sayre , =?ISO-8859-1?Q?Bill_de_h=D3ra?= , =?ISO-8859-1?Q?Martin_D=FCrst?= From: Henry Story Subject: Re: AtomAsRDF_PaceAttributesNS Date: Mon, 24 Jan 2005 20:45:31 +0100 To: Tim Bray X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit We are all working together on the proposal, in an iterative fashion. This is very similar to the way one develops software projects in Agile or Extreme programming methodology. First one starts with a prototype. One gets the major pieces in place, and gets general feedback from the clients. One checks that it works. Then one iteratively works towards a goal of getting something that satisfies the clients needs and budget. But you are correct to demand some real code. I have branched off the particular topic in AtomAsRDF_PaceAttributesNS [1], so that those that only want to work on detailed text, can get going debating and refining that. I would be very thankful if someone with more specification experience could get it into the correct final format. Yours sincerely, Henry Story [1] http://www.intertwingly.net/wiki/pie/AtomAsRDF_PaceAttributesNS On 24 Jan 2005, at 18:20, Tim Bray wrote: > On Jan 24, 2005, at 9:01 AM, Henry Story wrote: > >>>> Text close to the following should appear in the spec (please make >>>> more precise) >>>> ... >>> Who are you asking to make it more precise? -Tim >> >> whoever knows for example where it would be best placed in the spec, >> if it should replace some other sentence, if SHOULD should be >> capitalized, ... > > You don't understand. The only reality is the actual text in the > spec. Nothing else exists. Until there is an actual proposal for THE > ACTUAL WORDS that are going into the spec, there is nothing. The > reason is that after this WG goes away (which it will), the only > communication between us and the future is the content of the > specification. It is the only subject on which we can have a > meaningful debate. > > Serious discussion of this subject will not start until there is an > actual proposal placed before the WG. --Tim > From owner-atom-syntax@mail.imc.org Mon Jan 24 16: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 QAA02115 for ; Mon, 24 Jan 2005 16: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 j0OL3Uto086362; Mon, 24 Jan 2005 13:03: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 j0OL3Um8086361; Mon, 24 Jan 2005 13:03: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 j0OL3TOc086355 for ; Mon, 24 Jan 2005 13:03:30 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so146667rnz for ; Mon, 24 Jan 2005 13:03:22 -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=Y6d5H6LhWWIVmE2QnbSMQfJrFL7Utpj5DQrrQsYyiBfLIf9pjsDmJE0cnBw7MNJsrBDTTDvIFhGELPowvn64EMkGdtVUdx3tI+cC1/IJpIy12fMmRx5E0TBHuP4ZpBni9DM2dBATU60wROdqdyydWLmm2p1/G0uaMf1sNiEI79M= Received: by 10.38.8.52 with SMTP id 52mr490186rnh; Mon, 24 Jan 2005 13:03:22 -0800 (PST) Received: by 10.38.179.71 with HTTP; Mon, 24 Jan 2005 13:03:22 -0800 (PST) Message-ID: <1f2ed5cd050124130336fe7224@mail.gmail.com> Date: Mon, 24 Jan 2005 22:03:22 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Henry Story Subject: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS) Cc: Tim Bray , Atom Syntax , Robert Sayre , =?ISO-8859-1?Q?Bill_de_h=D3ra?= , =?ISO-8859-1?Q?Martin_D=FCrst?= In-Reply-To: <81D98645-6E40-11D9-91F1-000A95D9FA7A@bblfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4C9DF8A2-6C21-11D9-9797-000A95A51C9E@sun.com> <41F1C929.9070305@franklinmint.fm> <41F26238.9080907@dehora.net> <7EF03B50-6CA0-11D9-9797-000A95A51C9E@sun.com> <6.0.0.20.2.20050124121120.07392888@localhost> <453241F9-6E2C-11D9-9797-000A95A51C9E@sun.com> <81D98645-6E40-11D9-91F1-000A95D9FA7A@bblfish.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit "running code" ;-) http://www.intertwingly.net/wiki/pie/PaceAttributesNamespace == Abstract == Allow processors to interpret Atom attributes as being within the Atom namespace. == Status == Open == Rationale == Atom attributes are not in a namespace, which is likely to cause problems with interpretation of Atom documents by systems (such as RDF) which require absolutely qualified terms. == Proposal == To be inserted: {{{ Section 2. Atom Documents Atom processors MAY interpret unprefixed attribute names as their namespace-qualified equivalents. If they do, then all Atom attribute names MUST appear in the Atom namespace. }}} == Impacts == None == Notes == ---- CategoryProposals -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Mon Jan 24 17:07: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 RAA07984 for ; Mon, 24 Jan 2005 17:07: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 j0OLcvHQ089572; Mon, 24 Jan 2005 13:38: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 j0OLcvTb089571; Mon, 24 Jan 2005 13:38: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-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 j0OLcuQ1089563 for ; Mon, 24 Jan 2005 13:38:56 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (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 j0OLcq4R024502; Mon, 24 Jan 2005 16:38:52 -0500 (EST) Message-ID: <41F56AEC.7070606@intertwingly.net> Date: Mon, 24 Jan 2005 16:38: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: Henry Story CC: Atom Syntax Subject: Re: AtomAsRDF_PaceAttributesNS References: <4C9DF8A2-6C21-11D9-9797-000A95A51C9E@sun.com> <41F1C929.9070305@franklinmint.fm> <41F26238.9080907@dehora.net> <7EF03B50-6CA0-11D9-9797-000A95A51C9E@sun.com> <6.0.0.20.2.20050124121120.07392888@localhost> <453241F9-6E2C-11D9-9797-000A95A51C9E@sun.com> <81D98645-6E40-11D9-91F1-000A95D9FA7A@bblfish.net> In-Reply-To: <81D98645-6E40-11D9-91F1-000A95D9FA7A@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: > > We are all working together on the proposal, in an iterative fashion. > This is very similar to the way one develops software projects in Agile > or Extreme programming methodology. First one starts with a prototype. > One gets the major pieces in place, and gets general feedback from the > clients. > One checks that it works. Then one iteratively works towards a goal of > getting > something that satisfies the clients needs and budget. > > But you are correct to demand some real code. I have branched off the > particular > topic in AtomAsRDF_PaceAttributesNS [1], so that those that only want to > work on > detailed text, can get going debating and refining that. > > I would be very thankful if someone with more specification experience > could get > it into the correct final format. It is not "code" that Tim is asking for, but merely words. The specification is but a set of paragraphs, and somebody needs to say "insert words ". As to the words that you have proposed, I have a technical question: if you are equating unnamed attributes with attributes in the atom namespace, then everybody who looks today for an href attribute would *also* have to look for an atom:href attribute. Multiply this by all of the attributes defined in the specification, and IMHO, you have a solution that is *worse* than requiring the atom namespace in the first place. So, -1 From my perspective, Atom can be one XSLT translation away from RDF/XML, and will likely remain such. We can capture that translation as a non-normative appendix to the spec. We can also look at GRDDL or other techniques for making this explicit in the documents. But what I don't want is to make the syntax dramatially worse for people who want to use simple XML processing tools. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Jan 24 17: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 RAA08933 for ; Mon, 24 Jan 2005 17: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 j0OLr70a090134; Mon, 24 Jan 2005 13: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 j0OLr7pE090133; Mon, 24 Jan 2005 13:53:07 -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 j0OLr7Sr090113 for ; Mon, 24 Jan 2005 13:53: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 (rwcrmhc13) with SMTP id <20050124215254015009g5pee>; Mon, 24 Jan 2005 21:52:54 +0000 Date: Mon, 24 Jan 2005 14:52:52 -0700 Subject: Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS) 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: <1f2ed5cd050124130336fe7224@mail.gmail.com> Message-Id: <4C2C6F48-6E52-11D9-BA9F-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 24, 2005, at 02:03 PM, Danny Ayers wrote: > Atom processors MAY interpret unprefixed attribute names as their > namespace-qualified equivalents. > If they do, then all Atom attribute names MUST appear in the Atom > namespace. > I'd suggest slightly different language, such as: "Atom processors MAY interpret unprefixed attribute names in elements from the Atom namespace as if they were in the Atom namespace." Why I prefer the above: 1) It explicitly applies this rule only to Atom core elements--not extensions. 2) "their namespace-qualified equivalents": Unless the spec defines namespace-qualified attributes for Atom, which it doesn't, namespace-qualified equivalents don't actually exist, right? 3) It combines the two sentences, which I think is more clear. From owner-atom-syntax@mail.imc.org Mon Jan 24 18: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 SAA19547 for ; Mon, 24 Jan 2005 18: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 j0ONJ3qt094846; Mon, 24 Jan 2005 15:19: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 j0ONJ3cI094845; Mon, 24 Jan 2005 15:19:03 -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 j0ONJ2l5094838 for ; Mon, 24 Jan 2005 15:19:03 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (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 j0ONIuCh016929 for ; Mon, 24 Jan 2005 18:18:56 -0500 (EST) Message-ID: <41F5825F.6010901@intertwingly.net> Date: Mon, 24 Jan 2005 18:18:55 -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 Syntax Subject: AtomPubIssuesList for 2005/01/24 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 In consultation with the co-chairs (and Paul, I believe, will provide more details on where we go from here), I'm scheduling all the remaining format Paces. If successful, this document can move forward. If not, we will have a very good idea of what work is remaining, and hopefully can close that gap quickly. I'm recommending AtomAsRDF and PaceFeedRecursive for closure merely because they are incomplete. If they become complete, I will update their status accordingly. Note: I already have scheduled PaceAttributesNamespace which is a progeny of AtomAsRDF. For the remainder, there are two new Paces, PaceFeedLink, and PaceSimpleLanguageTagging. The remainder are ones that we have discussed before without resolution. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Jan 24 19: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 TAA20969 for ; Mon, 24 Jan 2005 19:08: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 j0ONgwO8096303; Mon, 24 Jan 2005 15:42: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 j0ONgwnr096302; Mon, 24 Jan 2005 15:42: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.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0ONgvaQ096296 for ; Mon, 24 Jan 2005 15:42:58 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so931rnz for ; Mon, 24 Jan 2005 15:42: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:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Z6hp2k+cWBerVV1ui0LLXjF2Md1BF70BZtn1v9Ek+4eXgHI6NCSIs9eC9KXJSmn4sdu/2l+OKTn5wRiUj1IKP/8hRd4aJ/hfxpmoujbXwEe4MlpNHU/rMjnjYnuibuJV3EvfKwBSrV41oUrYhYcop9HjjaWQpaHKBSKQ5NEykas= Received: by 10.38.206.28 with SMTP id d28mr3385rng; Mon, 24 Jan 2005 15:42:57 -0800 (PST) Received: by 10.38.179.71 with HTTP; Mon, 24 Jan 2005 15:42:57 -0800 (PST) Message-ID: <1f2ed5cd0501241542760cb7a4@mail.gmail.com> Date: Tue, 25 Jan 2005 00:42:57 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Antone Roundy Subject: Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS) Cc: atom-syntax@imc.org In-Reply-To: <4C2C6F48-6E52-11D9-BA9F-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd050124130336fe7224@mail.gmail.com> <4C2C6F48-6E52-11D9-BA9F-003065EA6144@geckotribe.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 24 Jan 2005 14:52:52 -0700, Antone Roundy wrote: > > On Monday, January 24, 2005, at 02:03 PM, Danny Ayers wrote: > > Atom processors MAY interpret unprefixed attribute names as their > > namespace-qualified equivalents. > > If they do, then all Atom attribute names MUST appear in the Atom > > namespace. > > > I'd suggest slightly different language, such as: > > "Atom processors MAY interpret unprefixed attribute names in elements > from the Atom namespace as if they were in the Atom namespace." > > Why I prefer the above: > > 1) It explicitly applies this rule only to Atom core elements--not > extensions. > 2) "their namespace-qualified equivalents": Unless the spec defines > namespace-qualified attributes for Atom, which it doesn't, > namespace-qualified equivalents don't actually exist, right? > 3) It combines the two sentences, which I think is more clear. Yep, I reckon that's an improvement. One thing I'm not sure about - where it currently says "Atom processors", perhaps that would be better as merely "Atom consumers". For the reasons Sam gave, we don't really want extra variability in what's being produced, but this still would still allow RDF-like consumers to interpret the feed as an RDF-like language. Does that make sense, or is there a case I'm missing here? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Mon Jan 24 19:26: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 TAA23316 for ; Mon, 24 Jan 2005 19:26: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 j0P00RFL096933; Mon, 24 Jan 2005 16:00: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 j0P00R6S096932; Mon, 24 Jan 2005 16:00:27 -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 j0P00Pxb096926 for ; Mon, 24 Jan 2005 16:00:26 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 24 Jan 2005 16:00:23 -0800 To: Atom WG From: Paul Hoffman Subject: The probably-last gang of issues Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greetings again. Sam's recent work queue rotation marks what we consider to be the likely final rotation before we are finished with the Atom format draft. That is, the goal is that, once we accept or close all of the items from the rotation, the format document editors will have a complete picture of what the WG wants in the Atom format spec. (For those of you new to this process, the full list of "currently under discussion" is at .) This ties in nicely with our goal of turning the format spec in for IETF Last Call before March. Of course, changes can (and probably will) be made based on the input to the WG from the IETF Last call. Those changes can come from the IETF community as a whole or from the WG as we stare one more time at the document (and as the implementers write code to it). However, there is a goal of not needing to revise the document after IETF Last Call; that is, we don't send the document to the IETF for review if we know that there are topics on which there is WG consensus that is not reflected in the document. So, please take a look at all of the Paces listed as "currently under discussion" and comment freely. We're getting close to being finished, which is of course the over-arching goal. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Jan 24 19:30: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 TAA23548 for ; Mon, 24 Jan 2005 19:30: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 j0P03pnd097123; Mon, 24 Jan 2005 16:03: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 j0P03pgk097122; Mon, 24 Jan 2005 16:03: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-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 j0P03kYI097112 for ; Mon, 24 Jan 2005 16:03:51 -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 j0P03kVu007149 for ; Mon, 24 Jan 2005 17:03:46 -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 <0IAU006JPIU9LG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:03:46 -0700 (MST) Received: from [192.168.1.11] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU000LEIU97R@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:03:45 -0700 (MST) Date: Mon, 24 Jan 2005 16:03:42 -0800 From: Tim Bray Subject: Stand by for a flurry of Pace overviews To: Atom Syntax Message-id: <92F9D008-6E64-11D9-9797-000A95A51C9E@textuality.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 Sam has updated our Public Issues List, and Paul has talked about about where we'd like to get to. I'm about to send fifteen separate messages, one for each of the 15 (!) format-related Paces up for their (hopefully) last go-around. These are the result of discussion between Paul and Sam and myself, and represent our take on what our consensus call would be if there were no further discussion. They may also prove to be convenient anchors for per-Pace discussion threads. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 19:35: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 TAA23783 for ; Mon, 24 Jan 2005 19:35: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 j0P0HqMS097989; Mon, 24 Jan 2005 16:17: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 j0P0HqJH097988; Mon, 24 Jan 2005 16:17:52 -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 j0P0HmsP097955 for ; Mon, 24 Jan 2005 16:17:48 -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 j0P0HmVu016297 for ; Mon, 24 Jan 2005 17:17:48 -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 <0IAU006K2JHNLG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:48 -0700 (MST) Received: from [192.168.1.11] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU00080JHG87@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:47 -0700 (MST) Date: Mon, 24 Jan 2005 16:17:46 -0800 From: Tim Bray Subject: PaceEntryDeletion status To: Atom Syntax Message-id: <8A3DBC8C-6E66-11D9-9797-000A95A51C9E@textuality.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 If there were no further discussion: The earlier discussion for this was inconclusive. The demand doesn't seem high enough to get it over the goal line, but if there is a wave of enthusiasm, there didn't seem to be that much opposition. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 19:36: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 TAA23868 for ; Mon, 24 Jan 2005 19:36: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 j0P0HvgY098045; Mon, 24 Jan 2005 16:17: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 j0P0HvsH098044; Mon, 24 Jan 2005 16:17:57 -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 j0P0Hu4O098030 for ; Mon, 24 Jan 2005 16:17:56 -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 j0P0HuVu016375 for ; Mon, 24 Jan 2005 17:17:56 -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 <0IAU006KKJHVLG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:56 -0700 (MST) Received: from [192.168.1.11] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU00080JHG87@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:56 -0700 (MST) Date: Mon, 24 Jan 2005 16:17:38 -0800 From: Tim Bray Subject: PaceSimpleLanguageTagging status To: Atom Syntax Message-id: <8521E062-6E66-11D9-9797-000A95A51C9E@textuality.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 Not yet taken up by the WG, depends on the discussion that comes with this call. Same rules as all the others: there has to be a positive WG consensus that each adds to the base specification. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 19:38: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 TAA23979 for ; Mon, 24 Jan 2005 19:38: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 j0P0HsPc098006; Mon, 24 Jan 2005 16:17: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 j0P0Hr3r098001; Mon, 24 Jan 2005 16:17: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 j0P0Hlin097920 for ; Mon, 24 Jan 2005 16:17: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 j0P0Hldv027057 for ; Mon, 24 Jan 2005 17:17: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 <0IAU006J8JHILG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:42 -0700 (MST) Received: from [192.168.1.11] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU00080JHG87@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:42 -0700 (MST) Date: Mon, 24 Jan 2005 16:17:41 -0800 From: Tim Bray Subject: PaceIRI status To: Atom Syntax Message-id: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.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 If there were no further discussion: It's hard to see how to avoid adopting this now that IRIs are standards-track RFC. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 19:43: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 TAA24473 for ; Mon, 24 Jan 2005 19:43: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 j0P0Hsq6098007; Mon, 24 Jan 2005 16:17: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 j0P0Hsvs098002; Mon, 24 Jan 2005 16:17:54 -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 j0P0Hpw0097983 for ; Mon, 24 Jan 2005 16:17:52 -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 j0P0HpVu016331 for ; Mon, 24 Jan 2005 17:17: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 <0IAU006Y6JHRHU@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:51 -0700 (MST) Received: from [192.168.1.11] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU00080JHG87@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:51 -0700 (MST) Date: Mon, 24 Jan 2005 16:17:39 -0800 From: Tim Bray Subject: PacePersonLinks status To: Atom Syntax Message-id: <85B8635B-6E66-11D9-9797-000A95A51C9E@textuality.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 If there were no further discussion: Has failed to get anywhere near enough support to call rough consensus in previous go-arounds. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 19:43: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 TAA24636 for ; Mon, 24 Jan 2005 19: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 j0P0Hpq8097972; Mon, 24 Jan 2005 16:17: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 j0P0Hol0097963; Mon, 24 Jan 2005 16:17:50 -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 j0P0HlnU097921 for ; Mon, 24 Jan 2005 16:17: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 j0P0Hldx027057 for ; Mon, 24 Jan 2005 17:17: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 <0IAU006JGJHJLG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:44 -0700 (MST) Received: from [192.168.1.11] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU00080JHG87@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:43 -0700 (MST) Date: Mon, 24 Jan 2005 16:17:42 -0800 From: Tim Bray Subject: PaceFeedState status To: Atom Syntax Message-id: <87B5897C-6E66-11D9-9797-000A95A51C9E@textuality.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 If there were no further discussion: Like PaceSupersede, this model of publishing does not (so far) enjoy consensus support. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 19: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 TAA24693 for ; Mon, 24 Jan 2005 19:44: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 j0P0Hp9q097986; Mon, 24 Jan 2005 16:17: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 j0P0HpfR097982; Mon, 24 Jan 2005 16:17: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 j0P0HlK4097923 for ; Mon, 24 Jan 2005 16:17: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 j0P0Hle3027057 for ; Mon, 24 Jan 2005 17:17: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 <0IAU006JQJHLLG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:45 -0700 (MST) Received: from [192.168.1.11] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU00080JHG87@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:45 -0700 (MST) Date: Mon, 24 Jan 2005 16:17:44 -0800 From: Tim Bray Subject: PaceFeedLink status To: Atom Syntax Message-id: <889E7EB6-6E66-11D9-9797-000A95A51C9E@textuality.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 Not yet taken up by the WG, depends on the discussion that comes with this call. Same rules as all the others: there has to be a positive WG consensus that each adds to the base specification. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 19:44: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 TAA24749 for ; Mon, 24 Jan 2005 19:44: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 j0P0Hs2t098004; Mon, 24 Jan 2005 16:17: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 j0P0HrPS098000; Mon, 24 Jan 2005 16:17: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 j0P0HoHc097962 for ; Mon, 24 Jan 2005 16:17:51 -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 j0P0Hodt027089 for ; Mon, 24 Jan 2005 17:17:50 -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 <0IAU006Y3JHPHU@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:50 -0700 (MST) Received: from [192.168.1.11] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU00080JHG87@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:49 -0700 (MST) Date: Mon, 24 Jan 2005 16:17:45 -0800 From: Tim Bray Subject: PaceExtensionConstruct status To: Atom Syntax Message-id: <893856C5-6E66-11D9-9797-000A95A51C9E@textuality.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 If there were no further discussion: This has received no -1s, but also not a lot of wild enthusiasm. Support at the moment is a bit marginal, but some +1s from implementors would probably make it a slam-dunk. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 19: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 TAA24873 for ; Mon, 24 Jan 2005 19: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 j0P0HsPK098003; Mon, 24 Jan 2005 16:17: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 j0P0HrD3097999; Mon, 24 Jan 2005 16:17: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 j0P0HoUe097961 for ; Mon, 24 Jan 2005 16:17:50 -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 j0P0Hndt027083 for ; Mon, 24 Jan 2005 17:17:49 -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 <0IAU006K5JHPLG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:49 -0700 (MST) Received: from [192.168.1.11] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU00080JHG87@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:49 -0700 (MST) Date: Mon, 24 Jan 2005 16:17:48 -0800 From: Tim Bray Subject: PaceEntriesAllTheWayDown status To: Atom Syntax Message-id: <8AF8AFC2-6E66-11D9-9797-000A95A51C9E@textuality.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 If there were no further discussion: This is a radical change to the document and, so far, hasn't gathered widespread enough support to make it over the line. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 19:47: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 TAA24919 for ; Mon, 24 Jan 2005 19:47: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 j0P0Hp6n097971; Mon, 24 Jan 2005 16:17: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 j0P0HojD097965; Mon, 24 Jan 2005 16:17:50 -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 j0P0HlWJ097922 for ; Mon, 24 Jan 2005 16:17: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 j0P0Hle1027057 for ; Mon, 24 Jan 2005 17:17: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 <0IAU006JGJHJLG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:44 -0700 (MST) Received: from [192.168.1.11] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU00080JHG87@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:44 -0700 (MST) Date: Mon, 24 Jan 2005 16:17:40 -0800 From: Tim Bray Subject: PaceMustBeWellFormed status To: Atom Syntax Message-id: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.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 If there were no further discussion: The WG completely failed to converge to consensus on these issues last time around. Consensus can still be found here. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 19:47: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 TAA24942 for ; Mon, 24 Jan 2005 19: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 j0P0Htf5098024; Mon, 24 Jan 2005 16:17: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 j0P0HtsM098023; Mon, 24 Jan 2005 16:17:55 -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 j0P0HsTn098005 for ; Mon, 24 Jan 2005 16:17:54 -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 j0P0HrVu016353 for ; Mon, 24 Jan 2005 17:17:53 -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 <0IAU006YCJHTHU@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:53 -0700 (MST) Received: from [192.168.1.11] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU00080JHG87@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:53 -0700 (MST) Date: Mon, 24 Jan 2005 16:17:51 -0800 From: Tim Bray Subject: PaceDateofSubject status To: Atom Syntax Message-id: <8CC1E471-6E66-11D9-9797-000A95A51C9E@textuality.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 If there were no further discussion: This topic was beaten to death a few times in the WG. Unless there is a wave of enthusiasm unaccompanied by -1s, the dates in the current Internet Draft will be all that ships with the final document. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 19:47: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 TAA24961 for ; Mon, 24 Jan 2005 19:47: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 j0P0HqoP097987; Mon, 24 Jan 2005 16:17: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 j0P0Hp25097984; Mon, 24 Jan 2005 16:17: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 j0P0Hlmh097924 for ; Mon, 24 Jan 2005 16:17: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 j0P0Hle5027057 for ; Mon, 24 Jan 2005 17:17: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 <0IAU006JYJHMLG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:47 -0700 (MST) Received: from [192.168.1.11] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU00080JHG87@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:46 -0700 (MST) Date: Mon, 24 Jan 2005 16:17:46 -0800 From: Tim Bray Subject: PaceExtendingAtom status To: Atom Syntax Message-id: <89BB7AD4-6E66-11D9-9797-000A95A51C9E@textuality.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 If there were no further discussion: This is the result of a lot of discussion around "Must Ignore" and has in various drafts received lots of friendly remarks and suggestions for improvement, which have been incorporated. Absent some convincing -1s, it probably goes in. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 19:47: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 TAA24987 for ; Mon, 24 Jan 2005 19:47: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 j0P0I31N098060; Mon, 24 Jan 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 j0P0I3Zu098059; Mon, 24 Jan 2005 16:18:03 -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 j0P0I2V2098051 for ; Mon, 24 Jan 2005 16:18:02 -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 j0P0I2Vu016443 for ; Mon, 24 Jan 2005 17:18:02 -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 <0IAU006L3JI1LG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:18:02 -0700 (MST) Received: from [192.168.1.11] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU00080JHG87@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:18:01 -0700 (MST) Date: Mon, 24 Jan 2005 16:18:00 -0800 From: Tim Bray Subject: PaceEnclosuresAndPix status To: Atom Syntax Message-id: <92798DAC-6E66-11D9-9797-000A95A51C9E@textuality.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 If there were no further discussion: Got no -1's, seems useful, needed for feature parity with RSS2, will likely go in absent some objections. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 19: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 TAA25157 for ; Mon, 24 Jan 2005 19:48: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 j0P0HvFL098042; Mon, 24 Jan 2005 16:17: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 j0P0HvVd098041; Mon, 24 Jan 2005 16:17:57 -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 j0P0HuDP098029 for ; Mon, 24 Jan 2005 16:17:56 -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 j0P0Hudt027125 for ; Mon, 24 Jan 2005 17:17:56 -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 <0IAU006KKJHVLG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:56 -0700 (MST) Received: from [192.168.1.11] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU00080JHG87@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:55 -0700 (MST) Date: Mon, 24 Jan 2005 16:17:50 -0800 From: Tim Bray Subject: PaceDateUpdated2 status To: Atom Syntax Message-id: <8C380201-6E66-11D9-9797-000A95A51C9E@textuality.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 If there were no further discussion: This topic was beaten to death a few times in the WG. Unless there is a wave of enthusiasm unaccompanied by -1s, the dates in the current Internet Draft will be all that ships with the final document. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 19: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 TAA25519 for ; Mon, 24 Jan 2005 19: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 j0P0HuvP098027; Mon, 24 Jan 2005 16:17: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 j0P0Hukb098026; Mon, 24 Jan 2005 16:17:56 -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 j0P0Hs5N098017 for ; Mon, 24 Jan 2005 16:17:55 -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 j0P0HsVu016362 for ; Mon, 24 Jan 2005 17:17:54 -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 <0IAU006YFJHUHU@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:54 -0700 (MST) Received: from [192.168.1.11] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU00080JHG87@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:54 -0700 (MST) Date: Mon, 24 Jan 2005 16:17:53 -0800 From: Tim Bray Subject: PaceAttributesNamespace status To: Atom Syntax Message-id: <8E003BC2-6E66-11D9-9797-000A95A51C9E@textuality.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 Not yet taken up by the WG, depends on the discussion that comes with this call. Same rules as all the others: there has to be a positive WG consensus that it adds to the base specification. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 20:20: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 UAA26932 for ; Mon, 24 Jan 2005 20:20: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 j0P0qAOs099820; Mon, 24 Jan 2005 16:52: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 j0P0qAVH099819; Mon, 24 Jan 2005 16:52:10 -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 j0P0qAHU099807 for ; Mon, 24 Jan 2005 16:52:10 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so51412rne for ; Mon, 24 Jan 2005 16:52: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=PNM87Lbvt92+mWBIlA4FzStGEHK6lexzYQNlSyWR3IuF4W2tH63yTlddC4KpzJPUxFq2t0Q5XimFE18A9z0LsR0MTQLj7Ex/psR2v/CUqRQMD6J/jLQoEeg9Uev6o07FnzWk1hjsyEgSU3LSt3W5IaPEVXmWwja/O4xTO7l46jg= Received: by 10.38.67.53 with SMTP id p53mr95288rna; Mon, 24 Jan 2005 16:52:09 -0800 (PST) Received: by 10.38.151.21 with HTTP; Mon, 24 Jan 2005 16:52:09 -0800 (PST) Message-ID: <3f1451f50501241652ebc0311@mail.gmail.com> Date: Mon, 24 Jan 2005 19:52:09 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Tim Bray Subject: Re: PaceEntryDeletion status Cc: Atom Syntax In-Reply-To: <8A3DBC8C-6E66-11D9-9797-000A95A51C9E@textuality.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <8A3DBC8C-6E66-11D9-9797-000A95A51C9E@textuality.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1 Too much of an edge case with no discenable benefit. On Mon, 24 Jan 2005 16:17:46 -0800, Tim Bray wrote: > > If there were no further discussion: The earlier discussion for this > was inconclusive. The demand doesn't seem high enough to get it over > the goal line, but if there is a wave of enthusiasm, there didn't seem > to be that much opposition. -Tim > > -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Jan 24 20:25: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 UAA27139 for ; Mon, 24 Jan 2005 20:25: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 j0P0xQ5c000740; Mon, 24 Jan 2005 16:59: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 j0P0xQ5u000739; Mon, 24 Jan 2005 16:59: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.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0P0xPrE000732 for ; Mon, 24 Jan 2005 16:59:25 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so52272rng for ; Mon, 24 Jan 2005 16:59:22 -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=cp6VX43sWSpd/a1TSmK09lVz9lGpoAROrqiquSClS2P/QFdVO7atdystftr74RoVEcUtWEljDqGc4Rh4arLG/arjJwee+6CwTqdCFt3tTp9auSm1fABOC8YhozkUQpR/eC+NOC/fTGsJzLyxXIX3ZJlkVMCz5JHtO3+nB3cusjk= Received: by 10.38.149.2 with SMTP id w2mr111130rnd; Mon, 24 Jan 2005 16:59:21 -0800 (PST) Received: by 10.38.151.21 with HTTP; Mon, 24 Jan 2005 16:59:21 -0800 (PST) Message-ID: <3f1451f50501241659610acb49@mail.gmail.com> Date: Mon, 24 Jan 2005 19:59:21 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Tim Bray Subject: Re: PaceExtensionConstruct status Cc: Atom Syntax In-Reply-To: <893856C5-6E66-11D9-9797-000A95A51C9E@textuality.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <893856C5-6E66-11D9-9797-000A95A51C9E@textuality.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1 to the general Pace, but I would prefer to see the 'Simple Extension' dropped. It adds a level of complexity that isn't requried. and for no discernable benefit. For example, the Pace states that " A Simple Extension construct MUST NOT have any attributes or child elements." Does that mean that a Simple Extension can't use xml:lang? Does a formerly Simple Extension become a Structured Extension if it requires internationalization? -joe On Mon, 24 Jan 2005 16:17:45 -0800, Tim Bray wrote: > > If there were no further discussion: This has received no -1s, but also > not a lot of wild enthusiasm. Support at the moment is a bit marginal, > but some +1s from implementors would probably make it a slam-dunk. > -Tim > > -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Jan 24 20:25: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 UAA27158 for ; Mon, 24 Jan 2005 20:25: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 j0P10YeN000816; Mon, 24 Jan 2005 17: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 j0P10YWK000815; Mon, 24 Jan 2005 17:00:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cat-proof.de (cat.cat-proof.de [213.239.198.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0P10XGI000806 for ; Mon, 24 Jan 2005 17:00:33 -0800 (PST) (envelope-from sc@itst.net) Received: from [192.168.1.11] (p50816DB2.dip0.t-ipconnect.de [80.129.109.178]) by cat-proof.de (Postfix) with ESMTP id 03535340B675 for ; Tue, 25 Jan 2005 01:56:46 +0100 (CET) Message-ID: <41F59A17.4050500@itst.net> Date: Tue, 25 Jan 2005 02:00:07 +0100 From: Sascha Carlin User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: Re: PaceSimpleLanguageTagging status References: <8521E062-6E66-11D9-9797-000A95A51C9E@textuality.com> In-Reply-To: <8521E062-6E66-11D9-9797-000A95A51C9E@textuality.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: > Not yet taken up by the WG, depends on the discussion that comes with > this call. Same rules as all the others: there has to be a positive WG > consensus that each adds to the base specification. -Tim +1, at least for atom:language inside the header. For elements, well, there _are_ use cases for elements in different languages, so, since it is optional, +1 again. Regards, Sascha From owner-atom-syntax@mail.imc.org Mon Jan 24 20:28: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 UAA27245 for ; Mon, 24 Jan 2005 20:28: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 j0P13Qx9000989; Mon, 24 Jan 2005 17: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 j0P13PVX000988; Mon, 24 Jan 2005 17:03:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scorpio.lunarpages.com (scorpio.lunarpages.com [64.235.234.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0P13PvP000971 for ; Mon, 24 Jan 2005 17:03:25 -0800 (PST) (envelope-from fielding@gbiv.com) Received: from wsip-24-248-98-242.oc.oc.cox.net ([24.248.98.242] helo=[10.2.8.58]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.43) id 1CtF70-0004V7-R5; Mon, 24 Jan 2005 17:03:18 -0800 In-Reply-To: <41F5825F.6010901@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> <41F5825F.6010901@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom-Syntax Syntax From: "Roy T. Fielding" Subject: Re: AtomPubIssuesList for 2005/01/24 Date: Mon, 24 Jan 2005 17:03:14 -0800 To: Sam Ruby X-Mailer: Apple Mail (2.619) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 24, 2005, at 3:18 PM, Sam Ruby wrote: > I'm recommending AtomAsRDF and PaceFeedRecursive for closure merely > because they are incomplete. If they become complete, I will update > their status accordingly. Note: I already have scheduled > PaceAttributesNamespace which is a progeny of AtomAsRDF. Why don't you just invent a status of "incomplete" and leave them off the table until completed? It doesn't make sense to close issues that are not resolved one way or another. I agree that they should not be considered until complete (meaning that they contain actual draft changes). ....Roy From owner-atom-syntax@mail.imc.org Mon Jan 24 20:28: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 UAA27267 for ; Mon, 24 Jan 2005 20: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 j0P122Wn000889; Mon, 24 Jan 2005 17:02: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 j0P122Ru000888; Mon, 24 Jan 2005 17:02:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cat-proof.de (cat.cat-proof.de [213.239.198.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0P121MY000881 for ; Mon, 24 Jan 2005 17:02:01 -0800 (PST) (envelope-from sc@itst.net) Received: from [192.168.1.11] (p50816DB2.dip0.t-ipconnect.de [80.129.109.178]) by cat-proof.de (Postfix) with ESMTP id B5373340B682 for ; Tue, 25 Jan 2005 01:58:21 +0100 (CET) Message-ID: <41F59A75.80602@itst.net> Date: Tue, 25 Jan 2005 02:01:41 +0100 From: Sascha Carlin User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: Re: PaceDateUpdated2 status References: <8C380201-6E66-11D9-9797-000A95A51C9E@textuality.com> In-Reply-To: <8C380201-6E66-11D9-9797-000A95A51C9E@textuality.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: > If there were no further discussion: This topic was beaten to death a > few times in the WG. Unless there is a wave of enthusiasm unaccompanied > by -1s, the dates in the current Internet Draft will be all that ships > with the final document. -Tim +1. I think this really is a consensus. FYI: From owner-atom-syntax@mail.imc.org Mon Jan 24 20: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 TAA24990 for ; Mon, 24 Jan 2005 19:47: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 j0P0Hpf8097979; Mon, 24 Jan 2005 16:17: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 j0P0HpCV097973; Mon, 24 Jan 2005 16:17: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 j0P0HlIW097919 for ; Mon, 24 Jan 2005 16:17: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 j0P0Hldt027057 for ; Mon, 24 Jan 2005 17:17: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 <0IAU006J5JHHLG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:41 -0700 (MST) Received: from [192.168.1.11] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU00080JHG87@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 17:17:41 -0700 (MST) Date: Mon, 24 Jan 2005 16:17:36 -0800 From: Tim Bray Subject: PaceSyntaxGuidelines status To: Atom Syntax Message-id: <842417DD-6E66-11D9-9797-000A95A51C9E@textuality.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 If there were no further discussion: Hasn't got enough support so far, but also has had no opposition we can find. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 20:35: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 UAA27925 for ; Mon, 24 Jan 2005 20:35: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 j0P18WrP003425; Mon, 24 Jan 2005 17:08: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 j0P18WAU003424; Mon, 24 Jan 2005 17:08:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cat-proof.de (cat.cat-proof.de [213.239.198.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0P18V3J003413 for ; Mon, 24 Jan 2005 17:08:31 -0800 (PST) (envelope-from sc@itst.net) Received: from [192.168.1.11] (p50816DB2.dip0.t-ipconnect.de [80.129.109.178]) by cat-proof.de (Postfix) with ESMTP id 88BDB340B675 for ; Tue, 25 Jan 2005 02:04:51 +0100 (CET) Message-ID: <41F59BFB.7020401@itst.net> Date: Tue, 25 Jan 2005 02:08:11 +0100 From: Sascha Carlin User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: Re: PaceDateofSubject status References: <8CC1E471-6E66-11D9-9797-000A95A51C9E@textuality.com> In-Reply-To: <8CC1E471-6E66-11D9-9797-000A95A51C9E@textuality.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: > If there were no further discussion: This topic was beaten to death a > few times in the WG. Unless there is a wave of enthusiasm unaccompanied > by -1s, the dates in the current Internet Draft will be all that ships > with the final document. That is, PaceDateOfSubject won't go in? +1 to that. Funny enough, I am listed as one of the supporters of this pace. In fact, I am not: From owner-atom-syntax@mail.imc.org Mon Jan 24 20:36: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 UAA28013 for ; Mon, 24 Jan 2005 20:36: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 j0P18pmO003627; Mon, 24 Jan 2005 17:08: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 j0P18pUB003626; Mon, 24 Jan 2005 17:08: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 j0P18o40003612 for ; Mon, 24 Jan 2005 17:08:50 -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 j0P18odt025372 for ; Mon, 24 Jan 2005 18:08:50 -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 <0IAU0058LLUPTZ@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 18:08:49 -0700 (MST) Received: from [192.168.1.11] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU000HULUO7R@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 18:08:49 -0700 (MST) Date: Mon, 24 Jan 2005 17:08:45 -0800 From: Tim Bray Subject: Re: PaceSyntaxGuidelines status In-reply-to: <3f1451f505012417025f5817e7@mail.gmail.com> To: Atom Syntax , Joe Gregorio 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: <842417DD-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f505012417025f5817e7@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 24, 2005, at 5:02 PM, Joe Gregorio wrote: > It reads like more of a guideline than a Pace. Inspecting the format > for conformance to these guidelines and generating Paces for > non-conformances seems like a better way to proceed than to actually > add this text to the spec. Actually, take a closer look, I got fooled too it first glance: It's talking about how *extensions* should use syntax, not how the spec should. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 20:36: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 UAA28063 for ; Mon, 24 Jan 2005 20:36: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 j0P19dkC003822; Mon, 24 Jan 2005 17:09: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 j0P19dqP003821; Mon, 24 Jan 2005 17:09: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.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0P19c9c003811 for ; Mon, 24 Jan 2005 17:09:38 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so54328rne for ; Mon, 24 Jan 2005 17:09: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=V4KhzhIctwWpe0NwiWVPbFxeFEgjmqHYNGa5C71MSYNUW0BiAqlbUnBanzKaM3zVPligX+uuDCb/IqM62HQNczgr3aMWx0L70Htp8ibRWhxcLtUywSdssIwzbI7qW7nKP9vqnksgp50LofxbNiDHSxtFaSQ78xZVO4vOPIqG0LE= Received: by 10.38.149.55 with SMTP id w55mr113626rnd; Mon, 24 Jan 2005 17:09:35 -0800 (PST) Received: by 10.38.151.21 with HTTP; Mon, 24 Jan 2005 17:09:35 -0800 (PST) Message-ID: <3f1451f5050124170960be6d43@mail.gmail.com> Date: Mon, 24 Jan 2005 20:09:35 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Tim Bray Subject: Re: PaceFeedState status Cc: Atom Syntax In-Reply-To: <87B5897C-6E66-11D9-9797-000A95A51C9E@textuality.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <87B5897C-6E66-11D9-9797-000A95A51C9E@textuality.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 From owner-atom-syntax@mail.imc.org Mon Jan 24 20:37: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 UAA28097 for ; Mon, 24 Jan 2005 20:37: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 j0P1C7nE003965; Mon, 24 Jan 2005 17:12: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 j0P1C74t003964; Mon, 24 Jan 2005 17:12:07 -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 j0P1C6Jx003944 for ; Mon, 24 Jan 2005 17:12:06 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so54719rne for ; Mon, 24 Jan 2005 17:12:01 -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=bFHfMzrd5/BxypOlyMoJZHeRzgyYM+AIQTrNNfFgI1bl2UVIDO+AXGodK1OTR3mcZztNi+iQHnosf6A0VjthU2B1xrsnDGdw8qQ+ZFiO2kwRyrGiXMwQKkPq5ZgbJ6xjglV3vkLzXrOkXxY6/HC9V5AjZLCNcUohhZuKh3+1Vx8= Received: by 10.38.67.53 with SMTP id p53mr107666rna; Mon, 24 Jan 2005 17:12:00 -0800 (PST) Received: by 10.38.151.21 with HTTP; Mon, 24 Jan 2005 17:12:00 -0800 (PST) Message-ID: <3f1451f505012417125b1e4d7c@mail.gmail.com> Date: Mon, 24 Jan 2005 20:12:00 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Tim Bray Subject: Re: PaceMustBeWellFormed status Cc: Atom Syntax In-Reply-To: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit It's good work but it belongs in a primer or best practices document. -joe On Mon, 24 Jan 2005 16:17:40 -0800, Tim Bray wrote: > > If there were no further discussion: The WG completely failed to > converge to consensus on these issues last time around. Consensus can > still be found here. -Tim > > -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Jan 24 20:41: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 UAA28409 for ; Mon, 24 Jan 2005 20:41: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 j0P1DbCk004133; Mon, 24 Jan 2005 17:13: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 j0P1DbX3004132; Mon, 24 Jan 2005 17:13: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0P1DbSa004125 for ; Mon, 24 Jan 2005 17:13:37 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id b11so32112rne for ; Mon, 24 Jan 2005 17:13: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=HOdkUcp2JqFsELFsF8hEEZYB3EI212AwFL4CW8pjCDgJfnsqyjviW+f79a5z4ajXomVdZ8SAO2Gq+TLIRLuTlQFm2qnjx/h/7xKslR9UC53hRXy2AqTkq5PVUTR/rJVNFxFtVNMy1YY4Voq/iSjxqlAEF9LpSEUDUqC7NrFD958= Received: by 10.38.162.17 with SMTP id k17mr222369rne; Mon, 24 Jan 2005 17:13:36 -0800 (PST) Received: by 10.38.151.21 with HTTP; Mon, 24 Jan 2005 17:13:36 -0800 (PST) Message-ID: <3f1451f5050124171362420c49@mail.gmail.com> Date: Mon, 24 Jan 2005 20:13:36 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Tim Bray Subject: Re: PaceFeedLink status Cc: Atom Syntax In-Reply-To: <889E7EB6-6E66-11D9-9797-000A95A51C9E@textuality.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <889E7EB6-6E66-11D9-9797-000A95A51C9E@textuality.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1 The alternative is that blasted feed:// URI type... -joe On Mon, 24 Jan 2005 16:17:44 -0800, Tim Bray wrote: > > Not yet taken up by the WG, depends on the discussion that comes with > this call. Same rules as all the others: there has to be a positive WG > consensus that each adds to the base specification. -Tim > > -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Jan 24 20: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 UAA28500 for ; Mon, 24 Jan 2005 20:42: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 j0P1GT0j004432; Mon, 24 Jan 2005 17: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 j0P1GTfO004431; Mon, 24 Jan 2005 17:16: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.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0P1GSVH004421 for ; Mon, 24 Jan 2005 17:16:28 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so55192rng for ; Mon, 24 Jan 2005 17:16: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=TKavC7wxjxGeuR4tNH+MuM4GVd9YowcqXgzDUBx5SjdBRZ5091yjGKEmL7kQMbWtDBpT8kjK0uwJjhmg65kDyiHrQaOflEp2wxIPmo2x8qGcNHgt2z6AYe37suUJmp06R463ivqnm8vEz3qOKH3RgNeyYxbDOcXWbFC35k2/8HA= Received: by 10.38.207.3 with SMTP id e3mr264968rng; Mon, 24 Jan 2005 17:16:23 -0800 (PST) Received: by 10.38.151.21 with HTTP; Mon, 24 Jan 2005 17:16:23 -0800 (PST) Message-ID: <3f1451f50501241716644d545c@mail.gmail.com> Date: Mon, 24 Jan 2005 20:16:23 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Tim Bray Subject: Re: PacePersonLinks status Cc: Atom Syntax In-Reply-To: <85B8635B-6E66-11D9-9797-000A95A51C9E@textuality.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <85B8635B-6E66-11D9-9797-000A95A51C9E@textuality.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1 If I understand all the Paces correctly, couldn't you get the same effect by including foaf as a Structured Extension of Person? -joe On Mon, 24 Jan 2005 16:17:39 -0800, Tim Bray wrote: > > If there were no further discussion: Has failed to get anywhere near > enough support to call rough consensus in previous go-arounds. -Tim > > -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Jan 24 20:43: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 UAA28596 for ; Mon, 24 Jan 2005 20:43: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 j0P1IMMv004735; Mon, 24 Jan 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 j0P1IMWP004734; Mon, 24 Jan 2005 17:18:22 -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 j0P1ILcZ004727 for ; Mon, 24 Jan 2005 17:18:21 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so55588rng for ; Mon, 24 Jan 2005 17:18:21 -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=UegFM55CWwZyN98a9algSYFbiZoyZ6P63LXdwpNjUDj9YIJVTFwztvJuC7QWlMxZhRH2sfTgKkaGrpz2rx4BCrXis7ymmwR58EaKMEe/dip3+GTUCYpPxL5iCN9nirc9EOr8X6Fna8Hq4fZnUBw1kpN3j56xZCJkgboX4op/qb0= Received: by 10.38.72.21 with SMTP id u21mr163868rna; Mon, 24 Jan 2005 17:18:20 -0800 (PST) Received: by 10.38.151.21 with HTTP; Mon, 24 Jan 2005 17:18:20 -0800 (PST) Message-ID: <3f1451f505012417187d37ae78@mail.gmail.com> Date: Mon, 24 Jan 2005 20:18:20 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Tim Bray Subject: Re: PaceEnclosuresAndPix status Cc: Atom Syntax In-Reply-To: <92798DAC-6E66-11D9-9797-000A95A51C9E@textuality.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <92798DAC-6E66-11D9-9797-000A95A51C9E@textuality.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1 Should there be a suggested size for images? -joe On Mon, 24 Jan 2005 16:18:00 -0800, Tim Bray wrote: > > If there were no further discussion: Got no -1's, seems useful, needed > for feature parity with RSS2, will likely go in absent some objections. > -Tim > > -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Jan 24 20:49: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 UAA28893 for ; Mon, 24 Jan 2005 20:49: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 j0P1M096005172; Mon, 24 Jan 2005 17:22: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 j0P1M077005171; Mon, 24 Jan 2005 17:22: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.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0P1Lx7S005142 for ; Mon, 24 Jan 2005 17:21:59 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so56395rne for ; Mon, 24 Jan 2005 17:21: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=IR929QLdkSkhyOuPQc3yqkf9YQ1MZqqLO3C02l/ToWLZuempekqyo5+WR0W/VRZn7OU0kSj7rQNR3a0D2nyPKf880RLHgC1uLBUjYHVfjQ544BYloZkhse1HpgDcWESATIUBFmgaxYCLYs4AdGkwTmgYTJIwP+2ZDzrBIrgC1QY= Received: by 10.38.149.55 with SMTP id w55mr123143rnd; Mon, 24 Jan 2005 17:21:54 -0800 (PST) Received: by 10.38.151.21 with HTTP; Mon, 24 Jan 2005 17:21:53 -0800 (PST) Message-ID: <3f1451f505012417214ce42e19@mail.gmail.com> Date: Mon, 24 Jan 2005 20:21:53 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Tim Bray Subject: Re: PaceExtendingAtom status Cc: Atom Syntax In-Reply-To: <89BB7AD4-6E66-11D9-9797-000A95A51C9E@textuality.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <89BB7AD4-6E66-11D9-9797-000A95A51C9E@textuality.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1 for making Atom a 'Must Ignore' language. On Mon, 24 Jan 2005 16:17:46 -0800, Tim Bray wrote: > > If there were no further discussion: This is the result of a lot of > discussion around "Must Ignore" and has in various drafts received lots > of friendly remarks and suggestions for improvement, which have been > incorporated. Absent some convincing -1s, it probably goes in. -Tim > > -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Jan 24 20: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 UAA28980 for ; Mon, 24 Jan 2005 20: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 j0P1PdLB005547; Mon, 24 Jan 2005 17:25: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 j0P1PdrB005546; Mon, 24 Jan 2005 17:25: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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0P1PccY005530 for ; Mon, 24 Jan 2005 17:25:38 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so56945rne for ; Mon, 24 Jan 2005 17:25: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=RZT6A8GGmGB98L7bVwUwPrT//mrf1SGcDpmJ/QXJActU2ET6cuVRGAJZZotg3fMo/TJbjr/XyuK3zREx8aV+rDsNeFslaK9kAKk+i/cGrkPxydEMmZHfpLM77TmzoTRftQi9RUZ/hHhfkLrWmbGg0fGTAbB7y/9AJPQ86hu3Ubc= Received: by 10.38.67.53 with SMTP id p53mr117792rna; Mon, 24 Jan 2005 17:25:33 -0800 (PST) Received: by 10.38.151.21 with HTTP; Mon, 24 Jan 2005 17:25:33 -0800 (PST) Message-ID: <3f1451f5050124172528e37264@mail.gmail.com> Date: Mon, 24 Jan 2005 20:25:33 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Tim Bray Subject: Re: PaceAttributesNamespace status Cc: Atom Syntax In-Reply-To: <8E003BC2-6E66-11D9-9797-000A95A51C9E@textuality.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <8E003BC2-6E66-11D9-9797-000A95A51C9E@textuality.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1 Ick. The only example given of a case where this may cause others problems is RDF, and I thought we were going to have a non-normative Atom -> RDF XSLT? Are there other cases I am unaware of? -joe On Mon, 24 Jan 2005 16:17:53 -0800, Tim Bray wrote: > > Not yet taken up by the WG, depends on the discussion that comes with > this call. Same rules as all the others: there has to be a positive WG > consensus that it adds to the base specification. -Tim > > -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Jan 24 20: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 UAA29129 for ; Mon, 24 Jan 2005 20:51: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 j0P1GhPs004469; Mon, 24 Jan 2005 17:16: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 j0P1GgOX004467; Mon, 24 Jan 2005 17:16:42 -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 j0P1GfTT004460 for ; Mon, 24 Jan 2005 17:16: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 j0P1GfVu019682 for ; Mon, 24 Jan 2005 18:16:41 -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 <0IAU0051MM7NTZ@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 18:16:35 -0700 (MST) Received: from [192.168.1.11] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU000K3M7M7R@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 18:16:35 -0700 (MST) Date: Mon, 24 Jan 2005 17:16:31 -0800 From: Tim Bray Subject: Re: PaceMustBeWellFormed status In-reply-to: <3f1451f505012417125b1e4d7c@mail.gmail.com> To: Joe Gregorio 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: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f505012417125b1e4d7c@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 24, 2005, at 5:12 PM, Joe Gregorio wrote: > It's good work but it belongs in a primer or best practices document. +1. I like it, I'd like to use it somewhere, but I don't think it belongs in the core spec. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 20:51: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 UAA29166 for ; Mon, 24 Jan 2005 20:51: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 j0P1Poos005565; Mon, 24 Jan 2005 17:25: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 j0P1PoH1005564; Mon, 24 Jan 2005 17:25:50 -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 j0P1PnbW005557 for ; Mon, 24 Jan 2005 17:25:49 -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 j0P1PmVu024708 for ; Mon, 24 Jan 2005 18:25:49 -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 <0IAU006NXMN0LG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 18:25:48 -0700 (MST) Received: from [192.168.1.11] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU000B4MMZ8A@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 18:25:48 -0700 (MST) Date: Mon, 24 Jan 2005 17:25:44 -0800 From: Tim Bray Subject: Re: PaceEnclosuresAndPix status In-reply-to: <3f1451f505012417187d37ae78@mail.gmail.com> To: Joe Gregorio Cc: Atom Syntax Message-id: <08F07334-6E70-11D9-9797-000A95A51C9E@textuality.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: <92798DAC-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f505012417187d37ae78@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT 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 From owner-atom-syntax@mail.imc.org Mon Jan 24 20:52: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 UAA29199 for ; Mon, 24 Jan 2005 20:52: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 j0P1RiXc005840; Mon, 24 Jan 2005 17:27: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 j0P1RiKI005839; Mon, 24 Jan 2005 17:27: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.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0P1RimA005828 for ; Mon, 24 Jan 2005 17:27:44 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id b11so33428rne for ; Mon, 24 Jan 2005 17:27:40 -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=iwXxxfVl4nvxK6HkqUhZ+bXTcCkkD1RQQUBpnc19VSwwS0HKf0ODbNwLh5hHfHjlVt1cdEFMQu5dgdsdHues/tsJHB7/z9yGgZKvLeNzvCIlDWNVF0PXNClvHGLPHPR4Zv+lCu7D4mDu1UrhycY1866DqYH8EqS48MNwNIoL8c8= Received: by 10.38.162.17 with SMTP id k17mr232487rne; Mon, 24 Jan 2005 17:27:40 -0800 (PST) Received: by 10.38.151.21 with HTTP; Mon, 24 Jan 2005 17:27:40 -0800 (PST) Message-ID: <3f1451f50501241727571ee117@mail.gmail.com> Date: Mon, 24 Jan 2005 20:27:40 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Tim Bray Subject: Re: PaceSyntaxGuidelines status Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <842417DD-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f505012417025f5817e7@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 24 Jan 2005 17:08:45 -0800, Tim Bray wrote: > > On Jan 24, 2005, at 5:02 PM, Joe Gregorio wrote: > > > It reads like more of a guideline than a Pace. Inspecting the format > > for conformance to these guidelines and generating Paces for > > non-conformances seems like a better way to proceed than to actually > > add this text to the spec. > > Actually, take a closer look, I got fooled too it first glance: It's > talking about how *extensions* should use syntax, not how the spec > should. -Tim In that case +1. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Jan 24 20:53: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 UAA29310 for ; Mon, 24 Jan 2005 20:53: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 j0P1STDw005907; Mon, 24 Jan 2005 17:28: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 j0P1STrB005905; Mon, 24 Jan 2005 17:28: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 j0P1SPqT005864 for ; Mon, 24 Jan 2005 17:28:27 -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, 25 Jan 2005 14:25:32 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 25 Jan 2005 12:24:50 +1100 Subject: Re: PaceEntryDeletion status From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <8A3DBC8C-6E66-11D9-9797-000A95A51C9E@textuality.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 25/1/05 11:17 AM, "Tim Bray" wrote: > If there were no further discussion: The earlier discussion for this > was inconclusive. The demand doesn't seem high enough to get it over > the goal line, but if there is a wave of enthusiasm, there didn't seem > to be that much opposition. -Tim -1 : edge case, doesn't cover all bases From owner-atom-syntax@mail.imc.org Mon Jan 24 20:54: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 UAA29468 for ; Mon, 24 Jan 2005 20:54: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 j0P1STAJ005904; Mon, 24 Jan 2005 17:28: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 j0P1STjW005903; Mon, 24 Jan 2005 17:28: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 j0P1SP4c005865 for ; Mon, 24 Jan 2005 17:28:27 -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, 25 Jan 2005 14:26:25 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 25 Jan 2005 12:25:42 +1100 Subject: Re: PacePersonLinks status From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <85B8635B-6E66-11D9-9797-000A95A51C9E@textuality.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 25/1/05 11:17 AM, "Tim Bray" wrote: > If there were no further discussion: Has failed to get anywhere near > enough support to call rough consensus in previous go-arounds. -Tim was that failure of consensus due to pushback on the very concept of itself (or related @rel disharmony), or actual disagreement with the use of in person? e. From owner-atom-syntax@mail.imc.org Mon Jan 24 20: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 UAA29655 for ; Mon, 24 Jan 2005 20:58: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 j0P1YLuK006522; Mon, 24 Jan 2005 17:34: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 j0P1YLqV006521; Mon, 24 Jan 2005 17:34:21 -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 ([161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0P1YKO0006484 for ; Mon, 24 Jan 2005 17:34:20 -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 j0P1X32E023100; Tue, 25 Jan 2005 01:33:13 GMT In-Reply-To: <8C380201-6E66-11D9-9797-000A95A51C9E@textuality.com> References: <8C380201-6E66-11D9-9797-000A95A51C9E@textuality.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--539435508; protocol="application/pkcs7-signature" Message-Id: <0E38D997-6E71-11D9-9153-000A95DC3D90@mac.com> Cc: Atom Syntax From: Graham Subject: Re: PaceDateUpdated2 status Date: Tue, 25 Jan 2005 01:33:02 +0000 To: Tim Bray X-Mailer: Apple Mail (2.619) 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-1--539435508 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 25 Jan 2005, at 12:17 am, Tim Bray wrote: > If there were no further discussion: This topic was beaten to death a > few times in the WG. Unless there is a wave of enthusiasm > unaccompanied by -1s, the dates in the current Internet Draft will be > all that ships with the final document. -Tim The language in the current draft is much cleaner, and I'd like to keep that. Since not much of this Pace is compatible with that language, the Pace itself is a -1. BUT, making the updated date optional is something I support. Anyone else? Graham --Apple-Mail-1--539435508 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 9w0BCQUxDxcNMDUwMTI1MDEzMzAzWjAjBgkqhkiG9w0BCQQxFgQU4jXyYl8yK3XnrDIgqaZsCRi8 mtQweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAycf5sTHgc6kTjrTRpvx87uU6 aN7OKExA+6a9rQkr/GrCyiZhTWCyEOIv/e9RnuARh/FZyIaUmqPWNguFugXMZrmkL0191IZgYI9T pqFVFv347zBNS/LCfUW1xm//vNraix3jUypMZPKPjmEF4N26ab5A+79hJrXzdwi9QTVaeAWgIlQD Ap4w235CspAsM9EpStFILGxKmTmrtT64AfY0idWAb94CC8cQqXjXVYcAn/GgQ1mKWGWCSltX3P23 EMuuyVW1x2G84oNi82p7FD3aGnLyIF/QldmuIuZEcix1rQmue7SP8YtalmYAFMqi5W6kkYOJbi74 Ww1gEqrSIOfiAwAAAAAAAA== --Apple-Mail-1--539435508-- From owner-atom-syntax@mail.imc.org Mon Jan 24 21:03: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 VAA29957 for ; Mon, 24 Jan 2005 21:03: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 j0P1eoxR006973; Mon, 24 Jan 2005 17: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 j0P1eoQl006972; Mon, 24 Jan 2005 17: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 j0P1enSY006953 for ; Mon, 24 Jan 2005 17: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 j0P1dsv1024205; Tue, 25 Jan 2005 01:39:54 GMT In-Reply-To: <8E003BC2-6E66-11D9-9797-000A95A51C9E@textuality.com> References: <8E003BC2-6E66-11D9-9797-000A95A51C9E@textuality.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--539024536; protocol="application/pkcs7-signature" Message-Id: <032E4B47-6E72-11D9-9153-000A95DC3D90@mac.com> Cc: Atom Syntax From: Graham Subject: Re: PaceAttributesNamespace status Date: Tue, 25 Jan 2005 01:39:54 +0000 To: Tim Bray X-Mailer: Apple Mail (2.619) 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--539024536 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 25 Jan 2005, at 12:17 am, Tim Bray wrote: > Not yet taken up by the WG, depends on the discussion that comes with > this call. Same rules as all the others: there has to be a positive WG > consensus that it adds to the base specification. -Tim -1 Unacceptable. Language is too broad and is meaningless outside the RDF context, which is where it should stay. Graham --Apple-Mail-3--539024536 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 9w0BCQUxDxcNMDUwMTI1MDEzOTU0WjAjBgkqhkiG9w0BCQQxFgQUfLDmpjTW7QfLPWRrCrL1/kM9 fl0weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEApjQGIuXhLPtI6R1f7WiYAY+L rxat6uycOQzxYz796VVlfmYdQdbAjwJ3rrEjbGEUcqCNtkicQXdhrVLUZCxR/6eD/5lGT+3CCO++ ByJkKo0hj6ItL37liCvAoKR4VpHK3eMLBg8GUVIYPlrWzvA99W/2Q2Di6lp74B8Els4GyBrUJSSa mvmi/1C1U0mF338z8ANXesYkYlzhjbu0lh4vhhhDktF+7+uZSXZ/OYSPd/lJiN58W6V8muOtnv6H v0TxuPCjJ4K1C1xgEYp/Mq4QQvovwG8+0vhjM4QvDK0zWperGwEq1lgTpmsmcLljUxwtCHiqKH2v 9GmmGupxxzYVegAAAAAAAA== --Apple-Mail-3--539024536-- From owner-atom-syntax@mail.imc.org Mon Jan 24 21:04: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 VAA00021 for ; Mon, 24 Jan 2005 21: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 j0P1ctVJ006837; Mon, 24 Jan 2005 17:38: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 j0P1ct1f006836; Mon, 24 Jan 2005 17:38: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 j0P1csnS006818 for ; Mon, 24 Jan 2005 17:38: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 j0P1buEb023940; Tue, 25 Jan 2005 01:37:56 GMT In-Reply-To: <8A3DBC8C-6E66-11D9-9797-000A95A51C9E@textuality.com> References: <8A3DBC8C-6E66-11D9-9797-000A95A51C9E@textuality.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--539142646; protocol="application/pkcs7-signature" Message-Id: Cc: Atom Syntax From: Graham Subject: Re: PaceEntryDeletion status Date: Tue, 25 Jan 2005 01:37:55 +0000 To: Tim Bray X-Mailer: Apple Mail (2.619) 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--539142646 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit -1 This approaches the problem from the wrong end. A better way to solve it would be to list entries that weren't deleted, but expired. A more complex solution would be to HEAD the link (or id or something) and see if you get a 404. Graham On 25 Jan 2005, at 12:17 am, Tim Bray wrote: > > If there were no further discussion: The earlier discussion for this > was inconclusive. The demand doesn't seem high enough to get it over > the goal line, but if there is a wave of enthusiasm, there didn't seem > to be that much opposition. -Tim > --Apple-Mail-2--539142646 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 9w0BCQUxDxcNMDUwMTI1MDEzNzU2WjAjBgkqhkiG9w0BCQQxFgQUXVxNpaNiYOVfRy4slIknvJ84 8EoweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAzBTN3YvngPYc6rFXN1rh5JDm 9xfqWCKhn1OULhpIUahXbI9KMnfky7Dqv0pQzH4kzQDgBv5ziXb+3RrAK9Mwc+G9o+DJkXp7iLwn jo4Q79/3hTLETiklsEs9Riyp2y2PRTbHj2BzPzjeeelL3JGzC7VidIHFng8JoLRHqt6Cq1hq8oCN asvk0X58JhlmmSRi10+7sH9gQY9+41hf30KrBtF2noStyx3ubOH+HZMkVOQBNRNm3ow+CRCOJzSS HDTHcqKu2bmwonpVUuMYDTizK+gyza3p1cRIlJtvLYfzXIGie7fpwO8knaygkYp2cDJW2hBkekL7 yCZyIoG+KN3IzwAAAAAAAA== --Apple-Mail-2--539142646-- From owner-atom-syntax@mail.imc.org Mon Jan 24 21:07: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 VAA00220 for ; Mon, 24 Jan 2005 21:07: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 j0P1flAj007100; Mon, 24 Jan 2005 17:41: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 j0P1flYb007099; Mon, 24 Jan 2005 17:41: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 j0P1fjbb007093 for ; Mon, 24 Jan 2005 17:41:46 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (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 j0P1ffKj019968; Mon, 24 Jan 2005 20:41:41 -0500 (EST) Message-ID: <41F5A3D4.1020007@intertwingly.net> Date: Mon, 24 Jan 2005 20:41:40 -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: Joe Gregorio CC: Atom Syntax Subject: Re: PaceExtensionConstruct status References: <893856C5-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f50501241659610acb49@mail.gmail.com> In-Reply-To: <3f1451f50501241659610acb49@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: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Joe Gregorio wrote: > +1 to the general Pace, but I would prefer to see > the 'Simple Extension' dropped. It adds a level of complexity > that isn't requried. and for no discernable benefit. > > For example, the Pace states that " A Simple Extension construct MUST > NOT have any attributes or child elements." Does that mean that a > Simple Extension can't use xml:lang? Does a formerly Simple Extension > become a Structured Extension if it requires internationalization? I work best with specific example. How should wfw:comment be handled? - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Jan 24 21:10: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 VAA00379 for ; Mon, 24 Jan 2005 21:10: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 j0P1amX2006716; Mon, 24 Jan 2005 17:36: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 j0P1am7S006715; Mon, 24 Jan 2005 17:36: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 j0P1agvG006701 for ; Mon, 24 Jan 2005 17:36:43 -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, 25 Jan 2005 14:37:21 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 25 Jan 2005 12:36:38 +1100 Subject: Re: Revisiting feed discovery From: Eric Scheid To: Arve Bersvendsen , 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 20/1/05 3:46 AM, "Arve Bersvendsen" wrote: >>> a) Change rel="alternate" to rel="feed", rel="subscription" or similar. >> >> On one (technical) level both make sense. However given that the >> current version is pretty widely deployed, a) at least could be >> counter-productive due to confusion. "alternate" might not be accurate >> in a lot of cases, but as a simple convention is near enough. > > I know that established convention dictates that we can never use anything > but "alternate", but this is overloading of the meaning of alternate - a > mistake I fear we'll have to pay for somewhere down the road. +1 to your concerns ... but then the Auto-Discovery spec is not yet an I-D so maybe there is still time? If we're stuck with 'alternate', then we're also harming the usefulness of Atom Entry Documents by not being able to intelligently link to them from their respective HTML pages. Similarly, if I had a feed which was "top new blog feeds I found", I can't sensibly put a link to the feed into the entries where I talk about them... in the following example, [1] is the link to the html page which is the alternate to this entry in this feed, but which is the link to the stand-alone Atom Entry Document for this entry, and which is the link to the URL to subscribe to "Foo's Feed"? foo's feed a wild and wacky feed about foo ... ... e. From owner-atom-syntax@mail.imc.org Mon Jan 24 21:11: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 VAA00440 for ; Mon, 24 Jan 2005 21:11: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 j0P1iJ5M007256; Mon, 24 Jan 2005 17:44: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 j0P1iJZM007255; Mon, 24 Jan 2005 17:44:19 -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 j0P1iIM7007246 for ; Mon, 24 Jan 2005 17:44:18 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so59848rng for ; Mon, 24 Jan 2005 17:44: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=MHMdmqu+oILjPXoFzilt7lq/eW0wS4oB40+pHovpl+QrmqU8VV0k7p4Y+hMKBmxeVGczLmyvtlkWr0plbC9JCGHJamTeFiko+7azw61+6ceBqnu6SyoVr7eoUNkoWx2JcK572Mp/xf59Md1IiZByvpqFsANsEZ8FTBkQbGgWbrI= Received: by 10.38.149.2 with SMTP id w2mr143838rnd; Mon, 24 Jan 2005 17:44:15 -0800 (PST) Received: by 10.38.151.21 with HTTP; Mon, 24 Jan 2005 17:44:15 -0800 (PST) Message-ID: <3f1451f5050124174423c81753@mail.gmail.com> Date: Mon, 24 Jan 2005 20:44:15 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Sam Ruby Subject: Re: PaceExtensionConstruct status Cc: Atom Syntax In-Reply-To: <41F5A3D4.1020007@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <893856C5-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f50501241659610acb49@mail.gmail.com> <41F5A3D4.1020007@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 24 Jan 2005 20:41:40 -0500, Sam Ruby wrote: > Joe Gregorio wrote: > > +1 to the general Pace, but I would prefer to see > > the 'Simple Extension' dropped. It adds a level of complexity > > that isn't requried. and for no discernable benefit. > > > > For example, the Pace states that " A Simple Extension construct MUST > > NOT have any attributes or child elements." Does that mean that a > > Simple Extension can't use xml:lang? Does a formerly Simple Extension > > become a Structured Extension if it requires internationalization? > > I work best with specific example. How should wfw:comment be handled? As a Structured Extension. Is there a benefit to being a 'Simple Extension' that I am missing? -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Jan 24 21:13: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 VAA00590 for ; Mon, 24 Jan 2005 21:13: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 j0P1koOF007428; Mon, 24 Jan 2005 17:46: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 j0P1korb007427; Mon, 24 Jan 2005 17:46: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 j0P1kn7g007419 for ; Mon, 24 Jan 2005 17:46: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 j0P1jR9V025018; Tue, 25 Jan 2005 01:46:10 GMT In-Reply-To: <8AF8AFC2-6E66-11D9-9797-000A95A51C9E@textuality.com> References: <8AF8AFC2-6E66-11D9-9797-000A95A51C9E@textuality.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5--538647992; protocol="application/pkcs7-signature" Message-Id: Cc: Atom Syntax From: Graham Subject: Re: PaceEntriesAllTheWayDown status Date: Tue, 25 Jan 2005 01:46:10 +0000 To: Tim Bray X-Mailer: Apple Mail (2.619) 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--538647992 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 25 Jan 2005, at 12:17 am, Tim Bray wrote: > If there were no further discussion: This is a radical change to the > document and, so far, hasn't gathered widespread enough support to > make it over the line. -Tim -1 Architectural astronautics at its most textbook. Graham --Apple-Mail-5--538647992 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 9w0BCQUxDxcNMDUwMTI1MDE0NjExWjAjBgkqhkiG9w0BCQQxFgQUPt/vqP0gso/0u2A0mdTdlNcz D2kweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAnmhnnLmX1m2GOq3LLWIhTYPM +AcI8KM7SYczbA5W+yR7XC5O4z8LEIlHUVOPCWlwJQhg2xSOD4b7+fzlkc60+1GmOfrqUWtEsSG2 6rgwZ1rdq2XHghgSjANhLOnyMR05Mtk4LIIMthFzWAfeiqsOSl1L0QNzTkA8uxU/9sMW6d1wSi0q gQnGLX0Td3DaFLZwcDJf0FEH5bwUuXLpx2RVhC7xc2JcjO69MOq9eRtHFJ7lqNS5I5n/SvWHRHAa ax2O21tSZjqV4BLqFamz1wsb5kBer4sQlJsKAIzgIXy4vKCXCXPD75JmTp7KlRZuuv/UvwzncGHM MJd5GFlaAElRswAAAAAAAA== --Apple-Mail-5--538647992-- From owner-atom-syntax@mail.imc.org Mon Jan 24 21:14: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 VAA00712 for ; Mon, 24 Jan 2005 21:14: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 j0P1jpar007378; Mon, 24 Jan 2005 17:45: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 j0P1jpNh007376; Mon, 24 Jan 2005 17:45:51 -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 j0P1jnf6007357; Mon, 24 Jan 2005 17:45: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 j0P1jR9U025018; Tue, 25 Jan 2005 01:45:27 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--538691057; protocol="application/pkcs7-signature" Message-Id: Cc: Atom WG From: Graham Subject: Re: The probably-last gang of issues Date: Tue, 25 Jan 2005 01:45:27 +0000 To: Paul Hoffman X-Mailer: Apple Mail (2.619) 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--538691057 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit 2 questions: 1. Is there a deadline for new feature proposals? Has it passed? There's one I want to make that depends on whether or not one in the current round is accepted. 2. The Pace process doesn't encourage proposing minor (editorial, style, etc) changes. It also seems to have encouraged proposals that are good in principle but poorly worded to be incorporated. Will there be a period of time for nitpicking and copyediting? Graham --Apple-Mail-4--538691057 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 9w0BCQUxDxcNMDUwMTI1MDE0NTI4WjAjBgkqhkiG9w0BCQQxFgQU9WSUjCY309asyOAssIXziNXC 3egweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAN5B/GEdSNrf4RPP3xkJo/v/Y BH4eRgQCsDFB+1vtAsefr7SI1wrBZSyXjzmql04P12o39AZaZ3nAgb8QBqT3XAE2jsqxUrgAGt1l kh5ZMmgTZq3TYJN2jp6Ryj+DjyNb1WsY7k/75vNvBiArMTolmugApiSqh2/BQxOoFbuF5CfsdiC9 vWkbmhkBIXwJWSWQ8uE+5A3wiN/FG9krXZgA0fW3lh+00OYqv3np3UZiAtaqSm6X2swAykvJSmux pw/y/zLcZc9hI3370gkOcnImn+TAoJ1nBsxrnAcpmnhUiodETV4HNAxpQX5fH/cPxqOg67kAPoEH 96XF+MIVpa8lzAAAAAAAAA== --Apple-Mail-4--538691057-- From owner-atom-syntax@mail.imc.org Mon Jan 24 21:14: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 UAA27275 for ; Mon, 24 Jan 2005 20: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 j0P12qrO000946; Mon, 24 Jan 2005 17:02: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 j0P12q2X000945; Mon, 24 Jan 2005 17:02:52 -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 j0P12ppH000939 for ; Mon, 24 Jan 2005 17:02:51 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id f1so39221rne for ; Mon, 24 Jan 2005 17:02:51 -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=hRUjpVOz6Zv1vAexQ1Kixqd7T/2ySKhR+7gA2x+iRVnoOZoOHUq0MXCTsOd8uztbFo+Ec7i0ijVAB5LjOqsnmw/8PZb4lAaJTzA6zQYZFFrGl1A6Qz6UeQq+D4cV4SwnHqWbxvHrs2irRrbVUqlS5a5eR7GIiiX5nnDhGq5bpVs= Received: by 10.38.72.21 with SMTP id u21mr151920rna; Mon, 24 Jan 2005 17:02:50 -0800 (PST) Received: by 10.38.151.21 with HTTP; Mon, 24 Jan 2005 17:02:50 -0800 (PST) Message-ID: <3f1451f505012417025f5817e7@mail.gmail.com> Date: Mon, 24 Jan 2005 20:02:50 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Tim Bray Subject: Re: PaceSyntaxGuidelines status Cc: Atom Syntax In-Reply-To: <842417DD-6E66-11D9-9797-000A95A51C9E@textuality.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <842417DD-6E66-11D9-9797-000A95A51C9E@textuality.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit It reads like more of a guideline than a Pace. Inspecting the format for conformance to these guidelines and generating Paces for non-conformances seems like a better way to proceed than to actually add this text to the spec. -joe On Mon, 24 Jan 2005 16:17:36 -0800, Tim Bray wrote: > > If there were no further discussion: Hasn't got enough support so far, > but also has had no opposition we can find. -Tim > > -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Jan 24 21:15: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 VAA00828 for ; Mon, 24 Jan 2005 21:15: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 j0P1l6bZ007448; Mon, 24 Jan 2005 17:47: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 j0P1l6Ga007447; Mon, 24 Jan 2005 17:47:06 -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 j0P1l59c007441 for ; Mon, 24 Jan 2005 17:47:05 -0800 (PST) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id CEE8F4F17E; Mon, 24 Jan 2005 20:47:02 -0500 (EST) Date: Mon, 24 Jan 2005 20:47:02 -0500 From: Dan Brickley To: Joe Gregorio Cc: Tim Bray , Atom Syntax Subject: Re: PaceFeedLink status Message-ID: <20050125014702.GA4566@homer.w3.org> References: <889E7EB6-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f5050124171362420c49@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3f1451f5050124171362420c49@mail.gmail.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: * Joe Gregorio [2005-01-24 20:13-0500] > > +1 The alternative is that blasted feed:// URI type... Yup, +1 from me too Dan From owner-atom-syntax@mail.imc.org Mon Jan 24 21:26: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 VAA01598 for ; Mon, 24 Jan 2005 21:26: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 j0P1vait008031; Mon, 24 Jan 2005 17:57: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 j0P1vaSp008030; Mon, 24 Jan 2005 17:57:36 -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 j0P1vZQq008023 for ; Mon, 24 Jan 2005 17:57:36 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (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 j0P1vXCh011859; Mon, 24 Jan 2005 20:57:33 -0500 (EST) Message-ID: <41F5A78B.3090001@intertwingly.net> Date: Mon, 24 Jan 2005 20:57:31 -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: Joe Gregorio CC: Atom Syntax Subject: Re: PaceExtensionConstruct status References: <893856C5-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f50501241659610acb49@mail.gmail.com> <41F5A3D4.1020007@intertwingly.net> <3f1451f5050124174423c81753@mail.gmail.com> In-Reply-To: <3f1451f5050124174423c81753@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: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Joe Gregorio wrote: > On Mon, 24 Jan 2005 20:41:40 -0500, Sam Ruby wrote: > >>Joe Gregorio wrote: >> >>>+1 to the general Pace, but I would prefer to see >>>the 'Simple Extension' dropped. It adds a level of complexity >>>that isn't requried. and for no discernable benefit. >>> >>>For example, the Pace states that " A Simple Extension construct MUST >>>NOT have any attributes or child elements." Does that mean that a >>>Simple Extension can't use xml:lang? Does a formerly Simple Extension >>>become a Structured Extension if it requires internationalization? >> >>I work best with specific example. How should wfw:comment be handled? > > As a Structured Extension. Is there a benefit to being a 'Simple > Extension' that I am missing? Again, let's talk about a specific example: http://bitworking.org/news/comments/52 Per the spec, one can reliably determine that wfw:comment can be interpreted as a simple property. In other words, one can be sure that if you don't currently see an attribute or child element, there never will be such on any other element. The overwhelming amount of extentions fall (example: most of the dc namespace) fall into this category. This is valuable for those who care about RDF. If this is dropped, I'm not sure what remains of this pace that is of value. If this pace as it currently stands expands the appeal of Atom to a broader audience, I'm +0 on the Pace. If this pace is modified so that it no longer serves this purpose than I am -1 on the Pace overall. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Jan 24 21:27: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 VAA01633 for ; Mon, 24 Jan 2005 21: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 j0P1vibv008044; Mon, 24 Jan 2005 17:57: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 j0P1viMQ008043; Mon, 24 Jan 2005 17:57:44 -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 j0P1vhak008037 for ; Mon, 24 Jan 2005 17:57:43 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 19391 invoked by uid 17064); 25 Jan 2005 01:57:43 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.251.47.143]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 25 Jan 2005 01:57:43 -0000 In-Reply-To: <3f1451f5050124172528e37264@mail.gmail.com> References: <8E003BC2-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f5050124172528e37264@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7FDD41A0-6E74-11D9-91F1-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: Re: PaceAttributesNamespace status Date: Tue, 25 Jan 2005 02:57:42 +0100 To: Joe Gregorio X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The point is to allow a very clear structure for Atom extensibility to be defined, as specified by the Atom working group charter. See AtomAsRDF and AtomOWL. The point of the exercise is to make this as invisible as possible to anyone other than those who need to write extensions. The intention is for this to have minimal impact on the spec. So if you don't care about writing or parsing atom extension, then you need not worry. Henry Story On 25 Jan 2005, at 02:25, Joe Gregorio wrote: > -1 Ick. > > The only example given of a case where this may cause others problems > is RDF, and I thought we were going to have a non-normative Atom -> > RDF XSLT? Are there other cases I am unaware of? > > -joe > > On Mon, 24 Jan 2005 16:17:53 -0800, Tim Bray > wrote: >> >> Not yet taken up by the WG, depends on the discussion that comes with >> this call. Same rules as all the others: there has to be a positive WG >> consensus that it adds to the base specification. -Tim >> >> > > > -- > Joe Gregorio http://bitworking.org > From owner-atom-syntax@mail.imc.org Mon Jan 24 21:28: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 VAA01692 for ; Mon, 24 Jan 2005 21:28: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 j0P1q6QJ007736; Mon, 24 Jan 2005 17:52: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 j0P1q6Nl007735; Mon, 24 Jan 2005 17:52:06 -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 j0P1q5Qe007727 for ; Mon, 24 Jan 2005 17:52:05 -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 j0P1ov7C026973; Tue, 25 Jan 2005 01:50:58 GMT In-Reply-To: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> References: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6--538360507; protocol="application/pkcs7-signature" Message-Id: <8EF909A8-6E73-11D9-9153-000A95DC3D90@mac.com> Cc: Atom Syntax From: Graham Subject: Re: PaceMustBeWellFormed status Date: Tue, 25 Jan 2005 01:50:57 +0000 To: Tim Bray X-Mailer: Apple Mail (2.619) 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--538360507 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 25 Jan 2005, at 12:17 am, Tim Bray wrote: > If there were no further discussion: The WG completely failed to > converge to consensus on these issues last time around. Consensus can > still be found here. -Tim -1 Phrases like "must be parsed with" seem to be dictating implementation rather than interop. Also it largely duplicates stuff found in RFCs Graham --Apple-Mail-6--538360507 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 9w0BCQUxDxcNMDUwMTI1MDE1MDU4WjAjBgkqhkiG9w0BCQQxFgQUBfCbZhj6xTIZJG1v5ZsiLCzW 70sweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAUOBqv7JumikEUmI+aATDyDtV vmKTyr8Wz4QTGsdWtNInBrw0vGBStTcLMDKi6gG8XSA5tu1m23vOh/48QVuprK3djFuCHyaJ9s4Y Cxa+aA5ZevHUkotfmhc/Qb7S/uCJPn1mGTQxpUL5eAKVERvfVFraD1qsZ3sOgovssBLTEZnW9nxH pZGIHKW3gT1Qh0++BndY+kxjQ01D+wXy+slzITbr848+2WdYdSe6jhPQsHbNOkUHcL8LiqCCs8E0 wmct7EOkcbYa/CZkdaDh8/nZkhlYpsTbrzHSoMP0+BDtBW16sFs+ThIARaDV1Y8Itxxz9xm5CIC8 xKN+26Uh/48bQgAAAAAAAA== --Apple-Mail-6--538360507-- From owner-atom-syntax@mail.imc.org Mon Jan 24 21:29: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 VAA01813 for ; Mon, 24 Jan 2005 21:29: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 j0P1r2AI007776; Mon, 24 Jan 2005 17:53: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 j0P1r2DI007774; Mon, 24 Jan 2005 17:53: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 j0P1qx7h007767; Mon, 24 Jan 2005 17:53:00 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: 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> <41F5825F.6010901@intertwingly.net> Date: Mon, 24 Jan 2005 17:52:56 -0800 To: "Roy T. Fielding" , Sam Ruby From: Paul Hoffman Subject: Re: AtomPubIssuesList for 2005/01/24 Cc: Atom-Syntax Syntax 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 5:03 PM -0800 1/24/05, Roy T. Fielding wrote: >Why don't you just invent a status of "incomplete" and leave >them off the table until completed? It doesn't make sense to >close issues that are not resolved one way or another. It does make sense this late in the process. As we said on the list, after this set of Paces is evaluated, we believe we're ready to go to IETF last call. We have to finish sometime, and on our milestone is a reasonable target. >I agree that they should not be considered until complete >(meaning that they contain actual draft changes). So, if you complete the Pace fairly quickly, it can be considered in this last round. If you don't, it would (should!) be dropped. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Jan 24 21:30: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 VAA01831 for ; Mon, 24 Jan 2005 21:30: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 j0P1wJ0L008068; Mon, 24 Jan 2005 17:58: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 j0P1wJib008067; Mon, 24 Jan 2005 17:58: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 j0P1wIis008061 for ; Mon, 24 Jan 2005 17:58:18 -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, 25 Jan 2005 14:58:59 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 25 Jan 2005 12:58:16 +1100 Subject: Re: PaceDateUpdated2 status From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <8C380201-6E66-11D9-9797-000A95A51C9E@textuality.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 25/1/05 11:17 AM, "Tim Bray" wrote: > If there were no further discussion: This topic was beaten to death a > few times in the WG. Unless there is a wave of enthusiasm unaccompanied > by -1s, the dates in the current Internet Draft will be all that ships > with the final document. -Tim This pace sought to clarify the distinction between date-updated and date-modified, and thus presumes the existence of , which got killed. It was written back in atom-01 days. As author, if I were to be considering bringing it up to date I would be changing the MAY to MUST, and otherwise dropping the last three paragraphs as redundant fluff. -1 I would suggest though that the word "modified" as in the current spec be avoided... that is, change the 04 spec text from this: The "atom:updated" element is a Date construct indicating the most recent instant in time when the entry was modified in a way the producer considers significant. Therefore, not all modifications necessarily result in a changed atom:updated value. to something like this: The "atom:updated" element is a Date construct indicating the most recent instant in time when the entry was changed in a way the producer considers significant. Therefore, not all changes necessarily result in a changed atom:updated value. The rationale for this is to avoid falsely giving hints that atom:updated should be blindly used for date-modified. Is this an editor-level change, or does it need a Pace? e. From owner-atom-syntax@mail.imc.org Mon Jan 24 21:30: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 VAA01879 for ; Mon, 24 Jan 2005 21:30: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 j0P1rqnb007800; Mon, 24 Jan 2005 17:53: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 j0P1rqSf007799; Mon, 24 Jan 2005 17:53:52 -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 j0P1rpuS007791 for ; Mon, 24 Jan 2005 17:53:51 -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 j0P1rYL4027510; Tue, 25 Jan 2005 01:53:34 GMT In-Reply-To: <3f1451f505012417187d37ae78@mail.gmail.com> References: <92798DAC-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f505012417187d37ae78@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7--538204360; protocol="application/pkcs7-signature" Message-Id: Cc: Atom Syntax , Tim Bray From: Graham Subject: Re: PaceEnclosuresAndPix status Date: Tue, 25 Jan 2005 01:53:34 +0000 To: Joe Gregorio X-Mailer: Apple Mail (2.619) 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--538204360 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 25 Jan 2005, at 1:18 am, Joe Gregorio wrote: > Should there be a suggested size for images? Yes. -1 on images section if suggested sizes aren't added. I think favicons are more commonly displayed than logo images, so a link type or at least suggested size for them would be welcome. Graham --Apple-Mail-7--538204360 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 9w0BCQUxDxcNMDUwMTI1MDE1MzM0WjAjBgkqhkiG9w0BCQQxFgQUubizAKi0+r8Kk+DAGDIG9J+p Y+0weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAzaQjE3fySY2SoREcINKqCDfX bx1uNeCs1KV5cDywMTAHWMxuZRRcu2KtszBZK36RzZIjTOwdn54PgXhrt55cYKmfiV46xAB7WnKK M+jrg0tOoqNcrgQjeg731lIg49x8Brqu02AqGt6uG1ImGAPQtC7LcCtO5sS7V+TRjkcTzVLyGNuc pvIPBhkuozovCD5Ljw1Iq4pfX6i2dUPskE3Kn8KxGTpIL2KLCmuW1Mbnlf8vy3gmQrvOnN2Iw4jJ K6O7roRbkjsPfTWlJ9TVEWNIXhFkKO/xKrzz2TZioX0JB479PYjCEP7WCU30Xtw2GiGdGkN6Zg1x xKGP7VBq09bs3AAAAAAAAA== --Apple-Mail-7--538204360-- From owner-atom-syntax@mail.imc.org Mon Jan 24 21:31: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 VAA01929 for ; Mon, 24 Jan 2005 21: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 j0P1rrb6007809; Mon, 24 Jan 2005 17:53: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 j0P1rr2J007808; Mon, 24 Jan 2005 17:53:53 -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 j0P1rrjD007802 for ; Mon, 24 Jan 2005 17:53:53 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 15451 invoked by uid 17064); 25 Jan 2005 01:53:53 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.251.47.143]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 25 Jan 2005 01:53:53 -0000 In-Reply-To: <41F56AEC.7070606@intertwingly.net> References: <4C9DF8A2-6C21-11D9-9797-000A95A51C9E@sun.com> <41F1C929.9070305@franklinmint.fm> <41F26238.9080907@dehora.net> <7EF03B50-6CA0-11D9-9797-000A95A51C9E@sun.com> <6.0.0.20.2.20050124121120.07392888@localhost> <453241F9-6E2C-11D9-9797-000A95A51C9E@sun.com> <81D98645-6E40-11D9-91F1-000A95D9FA7A@bblfish.net> <41F56AEC.7070606@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: Re: AtomAsRDF_PaceAttributesNS Date: Tue, 25 Jan 2005 02:53:54 +0100 To: Sam Ruby X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 24 Jan 2005, at 22:38, Sam Ruby wrote: > Henry Story wrote: >> We are all working together on the proposal, in an iterative fashion. >> This is very similar to the way one develops software projects in >> Agile >> or Extreme programming methodology. First one starts with a >> prototype. >> One gets the major pieces in place, and gets general feedback from >> the clients. >> One checks that it works. Then one iteratively works towards a goal >> of getting >> something that satisfies the clients needs and budget. >> But you are correct to demand some real code. I have branched off the >> particular >> topic in AtomAsRDF_PaceAttributesNS [1], so that those that only want >> to work on >> detailed text, can get going debating and refining that. >> I would be very thankful if someone with more specification >> experience could get >> it into the correct final format. > > It is not "code" that Tim is asking for, but merely words. The > specification is but a set of paragraphs, and somebody needs to say > "insert words ". I was using metaphorical language above, comparing methods taken from software engineering to the work of developing a spec. To be more precise spec writing was the tenor of the metaphor and software engineering the vehicle [1], and code perhaps the ground. I was taking properties from the software engineering vocabulary and applying them metaphorically to spec development. > As to the words that you have proposed, I have a technical question: > if you are equating unnamed attributes with attributes in the atom > namespace, then everybody who looks today for an href attribute would > *also* have to look for an atom:href attribute. Multiply this by all > of the attributes defined in the specification, and IMHO, you have a > solution that is *worse* than requiring the atom namespace in the > first place. So, I think Danny Ayers had a more complete proposal: PaceAttributesNamespace. > -1 > > From my perspective, Atom can be one XSLT translation away from > RDF/XML, and will likely remain such. The point of the trying to get the two closer together is that it makes it easier to explain very clearly structured extensibility. > We can capture that translation as a non-normative appendix to the > spec. We can also look at GRDDL or other techniques for making this > explicit in the documents. But what I don't want is to make the > syntax dramatially worse for people who want to use simple XML > processing tools. There is absolutely no impact on syntax. I think Danny's pace makes that clear. > > - Sam Ruby [1] http://en.wikipedia.org/wiki/Metaphor From owner-atom-syntax@mail.imc.org Mon Jan 24 21:34: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 VAA02105 for ; Mon, 24 Jan 2005 21:34: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 j0P28pUJ008564; Mon, 24 Jan 2005 18:08: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 j0P28p3r008563; Mon, 24 Jan 2005 18:08:51 -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 j0P28pVc008542 for ; Mon, 24 Jan 2005 18:08:51 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id g11so51291rne for ; Mon, 24 Jan 2005 18:08: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=JrVh2cvunkw8MYmP5Tz7T6WcKJWit86j8j+lgip5q9oW9a6BLPe1i4S8tNyxX9I3pcp5NUxPo7OHxc58NyQF2wdqEcL2bQshCUfHa7bRBR19tZe26JM9UDYJQcbFQjfzazT706kX2mNeZdrko5myz2pj2/bds5G8CV1UJ8c4ZDg= Received: by 10.39.1.23 with SMTP id d23mr186034rni; Mon, 24 Jan 2005 18:08:45 -0800 (PST) Received: by 10.38.151.21 with HTTP; Mon, 24 Jan 2005 18:08:45 -0800 (PST) Message-ID: <3f1451f505012418083f8fc9fc@mail.gmail.com> Date: Mon, 24 Jan 2005 21:08:45 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Henry Story Subject: Re: PaceAttributesNamespace status Cc: Atom Syntax In-Reply-To: <7FDD41A0-6E74-11D9-91F1-000A95D9FA7A@bblfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <8E003BC2-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f5050124172528e37264@mail.gmail.com> <7FDD41A0-6E74-11D9-91F1-000A95D9FA7A@bblfish.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 25 Jan 2005 02:57:42 +0100, Henry Story wrote: > The point is to allow a very clear structure for Atom extensibility to > be defined, as > specified by the Atom working group charter. See AtomAsRDF and AtomOWL. > The point > of the exercise is to make this as invisible as possible to anyone > other than those > who need to write extensions. The intention is for this to have minimal > impact on the > spec. So if you don't care about writing or parsing atom extension, > then you need not worry. I was looking for concrete examples beyond RDF, which, as I asserted, can be covered by an XSLT transformation. Since no others have been supplied I'll stick to my -1. -joe > > Henry Story > > On 25 Jan 2005, at 02:25, Joe Gregorio wrote: > > -1 Ick. > > > > The only example given of a case where this may cause others problems > > is RDF, and I thought we were going to have a non-normative Atom -> > > RDF XSLT? Are there other cases I am unaware of? > > > > -joe > > > > On Mon, 24 Jan 2005 16:17:53 -0800, Tim Bray > > wrote: > >> > >> Not yet taken up by the WG, depends on the discussion that comes with > >> this call. Same rules as all the others: there has to be a positive WG > >> consensus that it adds to the base specification. -Tim > >> > >> > > > > > > -- > > Joe Gregorio http://bitworking.org > > > > -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Jan 24 21:35: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 VAA02170 for ; Mon, 24 Jan 2005 21:35: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 j0P28Kf7008530; Mon, 24 Jan 2005 18:08: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 j0P28KLZ008529; Mon, 24 Jan 2005 18:08: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 j0P28JIs008523 for ; Mon, 24 Jan 2005 18:08:19 -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 j0P28JVu018222 for ; Mon, 24 Jan 2005 19:08:19 -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 <0IAU00502OLPTZ@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 24 Jan 2005 19:08:14 -0700 (MST) Received: from [192.168.1.15] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU006Q8OLP44@mail.sun.net> for atom-syntax@imc.org; Mon, 24 Jan 2005 19:08:13 -0700 (MST) Date: Mon, 24 Jan 2005 18:08:08 -0800 From: Tim Bray Subject: Re: PaceSyntaxGuidelines status In-reply-to: <842417DD-6E66-11D9-9797-000A95A51C9E@textuality.com> 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 References: <842417DD-6E66-11D9-9797-000A95A51C9E@textuality.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 24, 2005, at 4:17 PM, Tim Bray wrote: > > If there were no further discussion: Hasn't got enough support so far, > but also has had no opposition we can find. -Tim You know, I'd never really thought about this one, but now that I have, I wonder why on earth we should be trying to micromanage syntax for people we don't know writing extensions we know nothing about to solve problems we've never heard of... I'm veering toward -1. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 21:38: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 VAA02322 for ; Mon, 24 Jan 2005 21:37: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 j0P2AoDr008702; Mon, 24 Jan 2005 18: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 j0P2Aou5008701; Mon, 24 Jan 2005 18:10:50 -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 j0P2AmrJ008682 for ; Mon, 24 Jan 2005 18:10:49 -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 <20050125021030.OOTD2441.mta05-winn.mailhost.ntl.com@aamta05-winn.mailhost.ntl.com>; Tue, 25 Jan 2005 02:10:30 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta05-winn.mailhost.ntl.com with ESMTP id <20050125021030.UMCN769.aamta05-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Tue, 25 Jan 2005 02:10:30 +0000 Date: Tue, 25 Jan 2005 02:10:28 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <1742148530.20050125021028@djpowell.net> To: Joe Gregorio CC: Tim Bray , Atom Syntax Subject: Re: PaceExtensionConstruct status In-Reply-To: <3f1451f50501241659610acb49@mail.gmail.com> References: <893856C5-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f50501241659610acb49@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 Tuesday, January 25, 2005, 12:59:21 AM, you wrote: > +1 to the general Pace, but I would prefer to see > the 'Simple Extension' dropped. It adds a level of complexity > that isn't requried. and for no discernable benefit. It adds a few lines to the spec, but they are only relevant to extension authors. The benefit is that it allows a number of existing vocabularies to be used with Atom, without them needing rewriting for Atom. A large number of existing extensions already fit the Simple Extension model. I'll try to post my suggested RDF road-map tomorrow - basically, I'd like to see: * an Atom syntax - RDF mapping defined in a separate I-D. * no changes to the Atom syntax for the sake of RDF. * a model that maps properly onto the core Atom concepts without getting tangled up in the Atom syntax. This is almost possible now, but currently Atom extensions are just bits of XML hanging off the document - so it isn't easy to model an Atom document as anything other than XML. Simple Extensions are a compromise between defining some rigid structure for extension elements, and forcing extensions to be just represented as opaque bits of XML. For a lot of extensions I think they might be useful. They'd also be simple to implement in publishing clients so that a user could add a field to the form for a particular Simple Extension. > For example, the Pace states that " A Simple Extension construct MUST > NOT have any attributes or child elements." Does that mean that a > Simple Extension can't use xml:lang? Does a formerly Simple Extension > become a Structured Extension if it requires internationalization? After trying to use PaceExtensionConstruct to produce a mapping to RDF, I later raised PaceSimpleLanguageTagging to highlight the problem with xml:lang. If xml:lang is staying, then there are two options: a) xml:lang doesn't apply to Simple Extensions - if you need internationalisation, you need to use Structured Extensions. b) the range of a Simple Extension property is a (value, lang) pair. a) might be a reasonable compromise, looking at the list of extensions for RSS1.0 [1] few of them are language dependent (I couldn't find a list of RSS2.0 extensions). b) works fine for RDF interpretations, because RDF supports language tagged literals, but it is a bit clumsier for other models that don't. [1] http://web.resource.org/rss/1.0/modules/proposed.html -- Dave From owner-atom-syntax@mail.imc.org Mon Jan 24 21:38: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 VAA02347 for ; Mon, 24 Jan 2005 21:38: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 j0P28BZn008521; Mon, 24 Jan 2005 18:08: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 j0P28Bhs008520; Mon, 24 Jan 2005 18:08:11 -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 j0P289Zi008514; Mon, 24 Jan 2005 18:08:09 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 24 Jan 2005 18:08:06 -0800 To: Graham From: Paul Hoffman Subject: Re: The probably-last gang of issues 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 1:45 AM +0000 1/25/05, Graham wrote: >1. Is there a deadline for new feature proposals? Has it passed? It has passed. We have been talking about finishing for quite a while, and our March milestone is coming up quickly. > There's one I want to make that depends on whether or not one in >the current round is accepted. You are welcome to propose changes to current Paces if you feel that such a change will help gain consensus in the WG. >2. The Pace process doesn't encourage proposing minor (editorial, >style, etc) changes. Fully agree. > It also seems to have encouraged proposals that are good in >principle but poorly worded to be incorporated. Hopefully disagree, but I assume you have examples that I might go "oh, yeah, good point" to. > Will there be a period of time for nitpicking and copyediting? Absolutely. You can start now with the current draft, and we'll certainly have a bit of time after the next draft before we go to the IETF. After that latter round, we'll make a very fuzzy judgement call on whether to push the draft to the IETF anyhow or do another round with the editorial changes. Some of this will depend on a complete externality, namely the closed window for accepting Internet Drafts that happens before each IETF meeting. The cutoff is Monday, February 21st at 9:00 AM ET, and the window doesn't open again until Monday, March 7th. But we'll deal with that when we get closer to those deadlines, and by talking to Scott Hollenbeck, our illustrious AD. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Jan 24 21:38: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 VAA02382 for ; Mon, 24 Jan 2005 21:38: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 j0P2Bh97008774; Mon, 24 Jan 2005 18:11: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 j0P2Bg4F008772; Mon, 24 Jan 2005 18:11:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scorpio.lunarpages.com (scorpio.lunarpages.com [64.235.234.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0P2Bfle008755; Mon, 24 Jan 2005 18:11:41 -0800 (PST) (envelope-from fielding@gbiv.com) Received: from wsip-24-248-98-242.oc.oc.cox.net ([24.248.98.242] helo=[10.2.8.58]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.43) id 1CtGBA-0002Xw-0Q; Mon, 24 Jan 2005 18:11:40 -0800 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> <41F5825F.6010901@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <70E88FD6-6E76-11D9-BBF5-000D93324AD6@gbiv.com> Content-Transfer-Encoding: 7bit Cc: Sam Ruby , Atom-Syntax Syntax From: "Roy T. Fielding" Subject: Re: AtomPubIssuesList for 2005/01/24 Date: Mon, 24 Jan 2005 18:11:36 -0800 To: Paul Hoffman X-Mailer: Apple Mail (2.619) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 24, 2005, at 5:52 PM, Paul Hoffman wrote: > At 5:03 PM -0800 1/24/05, Roy T. Fielding wrote: >> Why don't you just invent a status of "incomplete" and leave >> them off the table until completed? It doesn't make sense to >> close issues that are not resolved one way or another. > > It does make sense this late in the process. As we said on the list, > after this set of Paces is evaluated, we believe we're ready to go to > IETF last call. We have to finish sometime, and on our milestone is a > reasonable target. Paul, you completely missed my point. The Pace isn't even open yet. It is incomplete. It is irrelevant. It is not closed. Marking it as closed takes it out of the incomplete pile and into the "finished" pile, which is just plain weird and unnecessary. You don't have to address incomplete suggestions -- just ignore them. ....Roy From owner-atom-syntax@mail.imc.org Mon Jan 24 21:39: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 VAA02443 for ; Mon, 24 Jan 2005 21:39: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 j0P2Bp5t008841; Mon, 24 Jan 2005 18: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 j0P2Bp1I008837; Mon, 24 Jan 2005 18:11: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 j0P2BlGb008816 for ; Mon, 24 Jan 2005 18:11:48 -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, 25 Jan 2005 15:12:28 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 25 Jan 2005 13:11:45 +1100 Subject: Re: PaceDateofSubject status From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <41F59BFB.7020401@itst.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 25/1/05 12:08 PM, "Sascha Carlin" wrote: > Funny enough, I am listed as one of the supporters of this pace. In fact, I am > not: That message of yours talks about "dateline", a similar concept but one which was discussed quite some time before DateOfSubject was proposed (July, vs September) You weren't in the original list of supporters, in fact you were added in the version of "2004-10-10 23:46:47" by userID "p508170DA". That's not me or any of the other editors of that Pace. I've taken your name off the Pace. e. From owner-atom-syntax@mail.imc.org Mon Jan 24 21: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 VAA03021 for ; Mon, 24 Jan 2005 21: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 j0P2Jq35009433; Mon, 24 Jan 2005 18:19: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 j0P2JqUR009432; Mon, 24 Jan 2005 18:19:52 -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 j0P2JoX4009404; Mon, 24 Jan 2005 18:19:51 -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 j0P2JWpG002247; Tue, 25 Jan 2005 02:19:37 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9--536646977; protocol="application/pkcs7-signature" Message-Id: <8C5101C2-6E77-11D9-9153-000A95DC3D90@mac.com> Cc: Atom WG From: Graham Subject: Re: The probably-last gang of issues Date: Tue, 25 Jan 2005 02:19:31 +0000 To: Paul Hoffman X-Mailer: Apple Mail (2.619) 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--536646977 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 25 Jan 2005, at 2:08 am, Paul Hoffman wrote: > At 1:45 AM +0000 1/25/05, Graham wrote: >> 1. Is there a deadline for new feature proposals? Has it passed? > > It has passed. We have been talking about finishing for quite a while, > and our March milestone is coming up quickly. That sounds like you making excuses for not having advertised the deadline in advance. >> It also seems to have encouraged proposals that are good in >> principle but poorly worded to be incorporated. > > Hopefully disagree, but I assume you have examples that I might go > "oh, yeah, good point" to. It's not so much examples, but I can't think of any times when a Pace has been rejected because of mediocre language. Thus if the principal is sound the Pace is accepted regardless. (though I will be listing examples willy and indeed nilly once the next draft is published) Graham --Apple-Mail-9--536646977 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 9w0BCQUxDxcNMDUwMTI1MDIxOTMyWjAjBgkqhkiG9w0BCQQxFgQU2/ieCoZwAFbl4Ho5/Dd9Tlck XL4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAHq1mOesqPGx0GH4cYmE6u1hq Nd2u783vwCsZB/hq2Lfpgtq7/4hLKR5v1XxF/Z+kC07SxdsgBXVbIIkehnGDYUNbUySENmSIt3Of UuASaNEN1n8uCER6rLd7Ow74rbtzBJGAm5A3VeLhZd5GUPzMOSXdy1W3pd6HxpsDnG2G5Idu3Lo3 JrUfXu310iff68Mjh6/oIWB20m0MW38mAn/NGtOgOpwsoqs6QXFFo9uUxkaFPRdKB4KfDetXTXIf v+1kE/nZbUSxzMZ7/bDwLZqyResBvQlWaADvuw9hUeJ2tCo406ywK0Jo/D+Q/oPaJpGD4zK6C9fa PzBL+kmWGALZygAAAAAAAA== --Apple-Mail-9--536646977-- From owner-atom-syntax@mail.imc.org Mon Jan 24 21:50: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 VAA03066 for ; Mon, 24 Jan 2005 21:50: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 j0P2NfJ1009740; Mon, 24 Jan 2005 18:23: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 j0P2NfLE009739; Mon, 24 Jan 2005 18:23:41 -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 j0P2NfVU009733 for ; Mon, 24 Jan 2005 18:23:41 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 66955 invoked by uid 17064); 25 Jan 2005 02:23:40 -0000 Received: from unknown (HELO [192.168.0.5]) ([193.251.47.143]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 25 Jan 2005 02:23:40 -0000 In-Reply-To: <3f1451f505012418083f8fc9fc@mail.gmail.com> References: <8E003BC2-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f5050124172528e37264@mail.gmail.com> <7FDD41A0-6E74-11D9-91F1-000A95D9FA7A@bblfish.net> <3f1451f505012418083f8fc9fc@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2165E3E7-6E78-11D9-91F1-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: Re: PaceAttributesNamespace status Date: Tue, 25 Jan 2005 03:23:41 +0100 To: Joe Gregorio X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit You can xslt convert anything to anything. That is not very helpful for defining an extensibility framework. Extensibility and a model are requirements for this working group. So these are central concerns. If you have an xslt based extensibiliy solution then please describe it in your own Pace. You will need to define not only how Atom maps to your preferred framework, but also how things can be expressed in that framework that extend Atom, and then how you can map the extended framework back into Atom with extensions. The proposal of which PaceAttributesNamespace is part of, AtomAsRDF, is a much simpler framework. It does not require the double mapping any other solution would. With very slight adjustements - which will be *completely invisible* to the end user (no rdf:li, no rdf:ul, no rdf:anything pretty much) we will be able to specify a very precise frameork. What I don't see is how you can object to a Pace that does not affect anything you need on grounds that you object to the aims the Pace is trying to fulfill, when those aims are central to the Atom working group. Henry Story On 25 Jan 2005, at 03:08, Joe Gregorio wrote: > On Tue, 25 Jan 2005 02:57:42 +0100, Henry Story > wrote: >> The point is to allow a very clear structure for Atom extensibility to >> be defined, as >> specified by the Atom working group charter. See AtomAsRDF and >> AtomOWL. >> The point >> of the exercise is to make this as invisible as possible to anyone >> other than those >> who need to write extensions. The intention is for this to have >> minimal >> impact on the >> spec. So if you don't care about writing or parsing atom extension, >> then you need not worry. > > I was looking for concrete examples beyond RDF, which, as I asserted, > can be covered by an XSLT transformation. Since no others have been > supplied I'll stick to my -1. > > -joe > >> >> Henry Story >> >> On 25 Jan 2005, at 02:25, Joe Gregorio wrote: >>> -1 Ick. >>> >>> The only example given of a case where this may cause others problems >>> is RDF, and I thought we were going to have a non-normative Atom -> >>> RDF XSLT? Are there other cases I am unaware of? >>> >>> -joe >>> >>> On Mon, 24 Jan 2005 16:17:53 -0800, Tim Bray >>> wrote: >>>> >>>> Not yet taken up by the WG, depends on the discussion that comes >>>> with >>>> this call. Same rules as all the others: there has to be a positive >>>> WG >>>> consensus that it adds to the base specification. -Tim >>>> >>>> >>> >>> >>> -- >>> Joe Gregorio http://bitworking.org >>> >> >> > > > -- > Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Jan 24 21:50: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 VAA03113 for ; Mon, 24 Jan 2005 21:50: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 j0P2OnHQ009831; Mon, 24 Jan 2005 18:24: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 j0P2OnwT009830; Mon, 24 Jan 2005 18:24:49 -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 j0P2Om7f009814 for ; Mon, 24 Jan 2005 18:24: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 <2005012502244301400hmpgee>; Tue, 25 Jan 2005 02:24:43 +0000 Date: Mon, 24 Jan 2005 19:24:42 -0700 Subject: Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS) 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: <1f2ed5cd0501241542760cb7a4@mail.gmail.com> Message-Id: <4540C0E8-6E78-11D9-BA9F-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 24, 2005, at 04:42 PM, Danny Ayers wrote: > On Mon, 24 Jan 2005 14:52:52 -0700, Antone Roundy > wrote: >> On Monday, January 24, 2005, at 02:03 PM, Danny Ayers wrote: >>> Atom processors MAY interpret unprefixed attribute names as their >>> namespace-qualified equivalents. >>> If they do, then all Atom attribute names MUST appear in the Atom >>> namespace. >>> >> I'd suggest slightly different language, such as: >> >> "Atom processors MAY interpret unprefixed attribute names in elements >> from the Atom namespace as if they were in the Atom namespace." >> >> Why I prefer the above: >> >> 1) It explicitly applies this rule only to Atom core elements--not >> extensions. >> 2) "their namespace-qualified equivalents": Unless the spec defines >> namespace-qualified attributes for Atom, which it doesn't, >> namespace-qualified equivalents don't actually exist, right? >> 3) It combines the two sentences, which I think is more clear. > > Yep, I reckon that's an improvement. > > One thing I'm not sure about - where it currently says "Atom > processors", perhaps that would be better as merely "Atom consumers". > For the reasons Sam gave, we don't really want extra variability in > what's being produced, but this still would still allow RDF-like > consumers to interpret the feed as an RDF-like language. > Does that make sense, or is there a case I'm missing here? > Agreed--"consumers" is better. Perhaps language should also be added to ensure that people know that they're not supposed to actually add a namespace prefix to the attributes. For example: "Atom consumers MAY interpret unprefixed attribute names in elements from the Atom namespace as if they were in the Atom namespace. However, Atom producers MUST NOT add a namespace prefix to attributes defined by the Atom format specification." BTW, am I remembering correctly that "xml:" in "xml:lang" and "xml:base" isn't a namespace prefix? You don't see xmlns:xml="..."--so is "xml:" not a namespace prefix, or does it just not have to be declared? If it IS a namespace prefix, then the above language works only if you don't consider publishing "xml:base" and "xml:lang" to be ADDING the prefix, since it was already there in the spec, but it may be possible to word it better. From owner-atom-syntax@mail.imc.org Mon Jan 24 21:52: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 VAA03237 for ; Mon, 24 Jan 2005 21:52: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 j0P2PpoK009948; Mon, 24 Jan 2005 18:25: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 j0P2Pp0w009947; Mon, 24 Jan 2005 18:25:51 -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 j0P2Porh009935 for ; Mon, 24 Jan 2005 18:25:51 -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 j0P2OxR6003238 for ; Tue, 25 Jan 2005 02:24:59 GMT Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <842417DD-6E66-11D9-9797-000A95A51C9E@textuality.com> References: <842417DD-6E66-11D9-9797-000A95A51C9E@textuality.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-10--536318969; protocol="application/pkcs7-signature" Message-Id: <4FD2D722-6E78-11D9-9153-000A95DC3D90@mac.com> From: Graham Subject: Re: PaceSyntaxGuidelines status Date: Tue, 25 Jan 2005 02:24:59 +0000 To: Atom WG X-Mailer: Apple Mail (2.619) 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--536318969 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 25 Jan 2005, at 12:17 am, Tim Bray wrote: > If there were no further discussion: Hasn't got enough support so far, > but also has had no opposition we can find. -Tim -1 I don't think it's useful or necessary. It's also a bit chatty. Graham --Apple-Mail-10--536318969 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 9w0BCQUxDxcNMDUwMTI1MDIyNDYwWjAjBgkqhkiG9w0BCQQxFgQUApnbHKeCbFuuuMtbi9mB39NV jEAweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAskLlHqQ4O3I0nqwBgF3qucwI nfDzaK37lU0gUGRD8ZRoXheiW81Rw4Uq6dQvEnJFhnuhIM/Fp1vahwPHi55D1zalt8/UHLLluPDe fv6ndm8bthVImYgkzDGJlO/3N0V/QD6maxjvY/UXmTbFnC2xCPEFIbDvah+z8dW9J3GjpyGy5paO XlJFHBqs3ocl2YRg5RCH0Bm2/WiAgtiiuhaqXsrUcEnf1O+7C9nHCSVq6oMSnJ4h5QIZW3e58QB3 Gd+3DMZTULtESps2A+cWAKMQo0cCh+j3ZlMNYOR8ZocfPECW+zOd+N5h5UD7K2XjHtSppQQVYnPO Kegly9yyNN0MdgAAAAAAAA== --Apple-Mail-10--536318969-- From owner-atom-syntax@mail.imc.org Mon Jan 24 21:54: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 VAA03346 for ; Mon, 24 Jan 2005 21:54: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 j0P2SNtH010064; Mon, 24 Jan 2005 18:28: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 j0P2SNx7010063; Mon, 24 Jan 2005 18:28:23 -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 j0P2SNiQ010057 for ; Mon, 24 Jan 2005 18:28:23 -0800 (PST) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id BCBCC4EFC5; Mon, 24 Jan 2005 21:28:22 -0500 (EST) Date: Mon, 24 Jan 2005 21:28:22 -0500 From: Dan Brickley To: Joe Gregorio Cc: Sam Ruby , Atom Syntax Subject: Re: PaceExtensionConstruct status Message-ID: <20050125022822.GB17039@homer.w3.org> References: <893856C5-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f50501241659610acb49@mail.gmail.com> <41F5A3D4.1020007@intertwingly.net> <3f1451f5050124174423c81753@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3f1451f5050124174423c81753@mail.gmail.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: * Joe Gregorio [2005-01-24 20:44-0500] > > On Mon, 24 Jan 2005 20:41:40 -0500, Sam Ruby wrote: > > Joe Gregorio wrote: > > > +1 to the general Pace, but I would prefer to see > > > the 'Simple Extension' dropped. It adds a level of complexity > > > that isn't requried. and for no discernable benefit. > > > > > > For example, the Pace states that " A Simple Extension construct MUST > > > NOT have any attributes or child elements." Does that mean that a > > > Simple Extension can't use xml:lang? Does a formerly Simple Extension > > > become a Structured Extension if it requires internationalization? > > > > I work best with specific example. How should wfw:comment be handled? > > As a Structured Extension. Is there a benefit to being a 'Simple > Extension' that I am missing? Is it that they're unconstrained enough that one might hope to generate a UI for any simple extension without knowing much about the particular properties being used? Answering a question with a question, Dan From owner-atom-syntax@mail.imc.org Mon Jan 24 21:54: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 VAA03376 for ; Mon, 24 Jan 2005 21:54: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 j0P2Sqr8010106; Mon, 24 Jan 2005 18:28: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 j0P2SqCS010105; Mon, 24 Jan 2005 18:28:52 -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 j0P2SpL7010092; Mon, 24 Jan 2005 18:28:51 -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 j0P2Spdt011687; Mon, 24 Jan 2005 19:28:51 -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 <0IAU0062FPK2LG@edgemail1.Central.Sun.COM>; Mon, 24 Jan 2005 19:28:51 -0700 (MST) Received: from [192.168.1.15] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAU006XIPK244@mail.sun.net>; Mon, 24 Jan 2005 19:28:50 -0700 (MST) Date: Mon, 24 Jan 2005 18:28:45 -0800 From: Tim Bray Subject: Re: The probably-last gang of issues In-reply-to: To: Graham Cc: Paul Hoffman , Atom WG 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: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 24, 2005, at 5:45 PM, Graham wrote: > 1. Is there a deadline for new feature proposals? Has it passed? > There's one I want to make that depends on whether or not one in the > current round is accepted. This being an IETF WG, you can always post a comment to a draft. If rough consensus occurs, in it goes. The current flurry is about achieving closure on a bunch of known issues, and about our belief that the Atom data format is getting nicely cooked; but the door isn't closed until the IESG says "done". > 2. The Pace process doesn't encourage proposing minor (editorial, > style, etc) changes. It also seems to have encouraged proposals that > are good in principle but poorly worded to be incorporated. Will there > be a period of time for nitpicking and copyediting? I think it's be just fine to have editorial and style and language debates right here on the WG any old time. It might be nice to put [Editorial] or some such in the subject line. -Tim From owner-atom-syntax@mail.imc.org Mon Jan 24 21:57: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 VAA03773 for ; Mon, 24 Jan 2005 21:57: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 j0P2Vt0W010291; Mon, 24 Jan 2005 18:31: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 j0P2VtAD010290; Mon, 24 Jan 2005 18:31:55 -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 j0P2Vrsd010284; Mon, 24 Jan 2005 18:31:54 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <8C5101C2-6E77-11D9-9153-000A95DC3D90@mac.com> References: <8C5101C2-6E77-11D9-9153-000A95DC3D90@mac.com> Date: Mon, 24 Jan 2005 18:31:50 -0800 To: Graham From: Paul Hoffman Subject: Re: The probably-last gang of issues 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:19 AM +0000 1/25/05, Graham wrote: >(though I will be listing examples willy and indeed nilly once the >next draft is published) Feel free to start listing them now. Waiting is OK too, but wording fixes suggested now will make the last steps even easier. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Jan 24 21: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 VAA03865 for ; Mon, 24 Jan 2005 21: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 j0P2ZfL1010643; Mon, 24 Jan 2005 18:35: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 j0P2Zfge010642; Mon, 24 Jan 2005 18:35: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-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 j0P2ZeKH010636 for ; Mon, 24 Jan 2005 18:35:41 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (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 j0P2Zb4R011126; Mon, 24 Jan 2005 21:35:38 -0500 (EST) Message-ID: <41F5B079.6090003@intertwingly.net> Date: Mon, 24 Jan 2005 21:35:37 -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: Danny Ayers CC: atom-syntax@imc.org Subject: Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS) References: <1f2ed5cd050124130336fe7224@mail.gmail.com> <4C2C6F48-6E52-11D9-BA9F-003065EA6144@geckotribe.com> <1f2ed5cd0501241542760cb7a4@mail.gmail.com> In-Reply-To: <1f2ed5cd0501241542760cb7a4@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: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > > One thing I'm not sure about - where it currently says "Atom > processors", perhaps that would be better as merely "Atom consumers". > For the reasons Sam gave, we don't really want extra variability in > what's being produced, but this still would still allow RDF-like > consumers to interpret the feed as an RDF-like language. > Does that make sense, or is there a case I'm missing here? I'm still struggling to understand what this is for. So, let me ramble for a few minutes... Assuming that there will be an XSLT which maps Atom to RDF, such an XSLT will have to map all unnamespaced attributes into something with a namespace. The namespace of the element is a reasonable choice. I'm a bit concerned about precedence rules (what happens if there is an href attribute *AND* an atom:href attribute?). What makes most sense here is for a prohibition disallowing such in any exension. I would support such a rule. Finally, I'm a bit concerned about round tripping - i.e., producing valid feeds from an RDF triple store. Given that an unnamespaced attribute and a namespaced attribute are two different things - how can a valid feed be produced? - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Jan 24 22:00: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 WAA03964 for ; Mon, 24 Jan 2005 22:00: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 j0P2Ylp4010552; Mon, 24 Jan 2005 18:34: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 j0P2YlEp010549; Mon, 24 Jan 2005 18:34: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 j0P2YkCN010530 for ; Mon, 24 Jan 2005 18:34:46 -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, 25 Jan 2005 15:31:47 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 25 Jan 2005 13:28:36 +1100 Subject: Re: PaceDateUpdated2 status From: Eric Scheid To: Graham CC: Atom Syntax Message-ID: In-Reply-To: <0E38D997-6E71-11D9-9153-000A95DC3D90@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 25/1/05 12:33 PM, "Graham" wrote: > BUT, making the updated date optional is something I support. Anyone > else? I originally thought so, but was willing to bend to the will of the developers that didn't like having an element that may or may not be there and thus required some manner of implied value or some such so sorting etc would work in some predictable manner. In a world where date-updated is optional, is it implied that an entry with no date-updated has a "last significant change date" being the date-published? I'd like it to be optional. If optional, then it's easy to leave out for those publishing systems that don't facilitate a method for subjectively marking an modification/edition/change as being "significant", and by not being required to be filled with something would thus not appear to so tempting a target for "date of last modification, no matter how trivial or banal". Did someone do a survey of what date concepts the various blog publishing systems support? e. From owner-atom-syntax@mail.imc.org Mon Jan 24 22:01: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 WAA03999 for ; Mon, 24 Jan 2005 22:01: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 j0P2YlC9010554; Mon, 24 Jan 2005 18:34: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 j0P2YlZF010551; Mon, 24 Jan 2005 18:34: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 j0P2Ykra010531 for ; Mon, 24 Jan 2005 18:34:46 -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, 25 Jan 2005 15:35:07 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 25 Jan 2005 13:34:24 +1100 Subject: Re: PaceFeedLink status From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <889E7EB6-6E66-11D9-9797-000A95A51C9E@textuality.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 25/1/05 11:17 AM, "Tim Bray" wrote: > Not yet taken up by the WG, depends on the discussion that comes with > this call. Same rules as all the others: there has to be a positive WG > consensus that each adds to the base specification. -Tim +1 for this pace - the tangible benefits to aggregators outweigh the unlikely negatives of a publisher spoofing some other feed's URI. e. From owner-atom-syntax@mail.imc.org Mon Jan 24 22:02: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 WAA04022 for ; Mon, 24 Jan 2005 22:02: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 j0P2YlU4010553; Mon, 24 Jan 2005 18:34: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 j0P2YluE010550; Mon, 24 Jan 2005 18:34: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 j0P2YkXo010529 for ; Mon, 24 Jan 2005 18:34:46 -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, 25 Jan 2005 15:31:45 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 25 Jan 2005 13:17:32 +1100 Subject: Re: PacePersonLinks status From: Eric Scheid To: Joe Gregorio CC: Atom Syntax Message-ID: In-Reply-To: <3f1451f50501241716644d545c@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 25/1/05 12:16 PM, "Joe Gregorio" wrote: > If I understand all the Paces correctly, couldn't you get the same > effect by including foaf as a Structured Extension of Person? only by including the foaf XML right there in the feed (oh the bloat!), or at least sufficient of the foaf XML to build a reference to a fuller foaf file elsewhere. and then you still don't have a means of providing a link to a non-foaf resource related to the person ... admittedly though you could by wrapping those links inside a foaf wrapper (which is just one more thing a publisher needs to learn how to do... ie. another opportunity to get something wrong). e. From owner-atom-syntax@mail.imc.org Mon Jan 24 22: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 WAA04379 for ; Mon, 24 Jan 2005 22:07: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 j0P2h1U7011225; Mon, 24 Jan 2005 18:43: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 j0P2h15r011224; Mon, 24 Jan 2005 18:43: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 j0P2h1aa011218 for ; Mon, 24 Jan 2005 18:43: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 1CtGfP-00018t-EM; Tue, 25 Jan 2005 02:42:55 +0000 Message-ID: <41F5B22D.9050407@franklinmint.fm> Date: Mon, 24 Jan 2005 21:42:53 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Gregorio CC: Tim Bray , Atom Syntax Subject: Re: PaceSyntaxGuidelines status References: <842417DD-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f505012417025f5817e7@mail.gmail.com> <3f1451f50501241727571ee117@mail.gmail.com> In-Reply-To: <3f1451f50501241727571ee117@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 Joe Gregorio wrote: > On Mon, 24 Jan 2005 17:08:45 -0800, Tim Bray wrote: > >>On Jan 24, 2005, at 5:02 PM, Joe Gregorio wrote: >> >> >>>It reads like more of a guideline than a Pace. Inspecting the format >>>for conformance to these guidelines and generating Paces for >>>non-conformances seems like a better way to proceed than to actually >>>add this text to the spec. >> >>Actually, take a closer look, I got fooled too it first glance: It's >>talking about how *extensions* should use syntax, not how the spec >>should. -Tim > > In that case +1. -1. Adds no value. Most people will look at the spec without reading it, imitate the examples, and end up with similar syntax anyway. People who take the time to read the spec are even less likely to do something ugly. That mostly leaves elements from existing vocabularies. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Jan 24 22:08: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 WAA04412 for ; Mon, 24 Jan 2005 22:08: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 j0P2d3bI010974; Mon, 24 Jan 2005 18: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 j0P2d3rL010973; Mon, 24 Jan 2005 18:39: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 j0P2d28o010961 for ; Mon, 24 Jan 2005 18:39: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 <2005012502385701300kf0oqe>; Tue, 25 Jan 2005 02:38:57 +0000 Date: Mon, 24 Jan 2005 19:38:55 -0700 Subject: Re: PaceSyntaxGuidelines status 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: <842417DD-6E66-11D9-9797-000A95A51C9E@textuality.com> Message-Id: <4231CF23-6E7A-11D9-BA9F-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 > 7.2 Common element usage > > The following actual elements should only be used in the ways > specified below. > > * link: Purposes of link elements are specified by a list of legal > values for link/@rel, and we are considering allowing extensions to > specify additional values. If the external resource being referred to > is not one that would make sense to present to the user as a clickable > link, some other element should be used instead. For example, link is > used to point to an alternate representation of the content of the > entry, to the next set of entries in a feed, etc. The link element is > not appropriate for pointing to things like a stylesheet for the feed, > an XSL template, etc., which are not intended for viewing by the user. Although I'm in favor of this concept, the workgroup has rejected efforts to incorporate such language into the definition of link constructs. Are we going to recommend this for extensions if we're not going to hold the core to it? If so, this section needs rewording. From owner-atom-syntax@mail.imc.org Mon Jan 24 22:08: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 WAA04440 for ; Mon, 24 Jan 2005 22:08: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 j0P2gHd9011205; Mon, 24 Jan 2005 18:42: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 j0P2gH0v011204; Mon, 24 Jan 2005 18:42: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 j0P2gGj0011198 for ; Mon, 24 Jan 2005 18:42:16 -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 501934EFB4; Mon, 24 Jan 2005 21:42:14 -0500 (EST) Message-Id: <6.0.0.20.2.20050125113534.0757c3e8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 25 Jan 2005 11:42:14 +0900 To: Sam Ruby , Henry Story From: Martin Duerst Subject: Re: AtomAsRDF_PaceAttributesNS Cc: Atom Syntax In-Reply-To: <41F56AEC.7070606@intertwingly.net> References: <4C9DF8A2-6C21-11D9-9797-000A95A51C9E@sun.com> <41F1C929.9070305@franklinmint.fm> <41F26238.9080907@dehora.net> <7EF03B50-6CA0-11D9-9797-000A95A51C9E@sun.com> <6.0.0.20.2.20050124121120.07392888@localhost> <453241F9-6E2C-11D9-9797-000A95A51C9E@sun.com> <81D98645-6E40-11D9-91F1-000A95D9FA7A@bblfish.net> <41F56AEC.7070606@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 At 06:38 05/01/25, Sam Ruby wrote: > >Henry Story wrote: >> We are all working together on the proposal, in an iterative fashion. >> This is very similar to the way one develops software projects in Agile >> or Extreme programming methodology. First one starts with a prototype. >> One gets the major pieces in place, and gets general feedback from the clients. >> One checks that it works. Then one iteratively works towards a goal of getting >> something that satisfies the clients needs and budget. >> But you are correct to demand some real code. I have branched off the particular >> topic in AtomAsRDF_PaceAttributesNS [1], so that those that only want to work on >> detailed text, can get going debating and refining that. >> I would be very thankful if someone with more specification experience could get >> it into the correct final format. > >It is not "code" that Tim is asking for, but merely words. The specification is but a set of paragraphs, and somebody needs to say "insert words ". > >As to the words that you have proposed, I have a technical question: if you are equating unnamed attributes with attributes in the atom namespace, then everybody who looks today for an href attribute would *also* have to look for an atom:href attribute. Multiply this by all of the attributes defined in the specification, and IMHO, you have a solution that is *worse* than requiring the atom namespace in the first place. So, > > -1 That's not the way I have understood this. What I thought this to be is: In Atom, these attributes always are unprefixed. They are in the Atom namespace just for the purposes of RDF. > From my perspective, Atom can be one XSLT translation away from RDF/XML, and will likely remain such. We can capture that translation as a non-normative appendix to the spec. We can also look at GRDDL or other techniques for making this explicit in the documents. But what I don't want is to make the syntax dramatially worse for people who want to use simple XML processing tools. Agreed. I just saw the text that we would insert into the spec as a verbal description of one aspect (adding an Atom-namespace prefix) of that transformation. But I can see that the current text, "Processors should interpret unprefixed attributes in atom namespaced elements to be in the atom namespace", can easily be interpreted the way you have done it. I think this can be fixed by changing it to something like "For the purpose of transformation to or interpretation as RDF, unprefixed attributes in atom namespaced elements to be interpreted as being in the atom namespace." I guess that Henry didn't add the clarification because he saw the text in the context of an overall AtomAsRDF section, which would make the context clear enough. Regards, Martin. From owner-atom-syntax@mail.imc.org Mon Jan 24 22:12: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 WAA04538 for ; Mon, 24 Jan 2005 22:12: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 j0P2j9QX011386; Mon, 24 Jan 2005 18:45: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 j0P2j9NT011385; Mon, 24 Jan 2005 18:45:09 -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 j0P2j8Ya011379 for ; Mon, 24 Jan 2005 18:45:08 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (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 j0P2j4Kj022627; Mon, 24 Jan 2005 21:45:04 -0500 (EST) Message-ID: <41F5B2B0.80203@intertwingly.net> Date: Mon, 24 Jan 2005 21:45:04 -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 Syntax Subject: Re: PaceExtensionConstruct status References: <893856C5-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f50501241659610acb49@mail.gmail.com> <1742148530.20050125021028@djpowell.net> In-Reply-To: <1742148530.20050125021028@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: > (I couldn't find a list of RSS2.0 extensions). http://blogs.law.harvard.edu/tech/directory/5/specifications/rss20ModulesNamespaces - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Jan 24 22:19: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 WAA04844 for ; Mon, 24 Jan 2005 22:19: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 j0P2mr4R011674; Mon, 24 Jan 2005 18: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 j0P2mrTV011673; Mon, 24 Jan 2005 18:48: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 j0P2mpJq011665 for ; Mon, 24 Jan 2005 18:48:52 -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, 25 Jan 2005 15:49:32 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 25 Jan 2005 13:48:49 +1100 Subject: Re: PaceExtensionConstruct status From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1742148530.20050125021028@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: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 25/1/05 1:10 PM, "David Powell" wrote: > The benefit is that it allows a number of existing vocabularies to be > used with Atom, without them needing rewriting for Atom. example please e. From owner-atom-syntax@mail.imc.org Mon Jan 24 22:19: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 WAA04874 for ; Mon, 24 Jan 2005 22:19: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 j0P2sc6A011969; Mon, 24 Jan 2005 18: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 j0P2sc9N011968; Mon, 24 Jan 2005 18:54:38 -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 j0P2sbfv011958 for ; Mon, 24 Jan 2005 18:54: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 (sccrmhc13) with SMTP id <2005012502543201600hl9bae>; Tue, 25 Jan 2005 02:54:32 +0000 Date: Mon, 24 Jan 2005 19:54:30 -0700 Subject: Re: PaceFeedState status 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: <3f1451f5050124170960be6d43@mail.gmail.com> Message-Id: <6F387BAC-6E7C-11D9-BA9F-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 24, 2005, at 06: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 " Agreed, agreed and agreed. "When a new Atom Feed Document is received by a consumer, the entries in it are compared to those that are already known to belong to the same Atom Feed, in reverse document order (that is, starting with the last entry in the Atom Feed Document and working towards the first). If an entry from the document has the same 'id' attribute as an existing entry, the metadata associated with it replaces that currently associated with the entry completely. Any existing metadata, whether or not present in the new entry, is removed." I think this is beyond the scope of the specification. First, the "reverse document order" part is unnecessary and inappropriate. Second, the client may keep the history of an entry--we shouldn't be mandating that the old metadata be discarded. "By following such links progressively backwards and incorporating the changes in each associated Atom Link document, until it encounters a link to a document it already has seen (as identified by the //atom:head/atom:link[@rel='this'] element), a consumer can reconstruct the state of a feed reliably." I'm not sure I'm in favor of this method. If, for example, the "sliding window" into one's feed contains 15 entries, and the "prev" link points to the prior 15 entries, unless one polls when a multiple of 15 entries have been added, you'll never see the same batch of entries you saw last time. Of course, feeds could be implemented in a way that avoided this problem...and I'm not sure I can think of a better method off hand. If for example you were to keep going backward till one saw an entry/id they'd seen before, you might stop too early if an entry had been altered and moved nearer the top of the feed. If you were to try to avoid this mistake by checking entry/updated for a change, you could still fail if the publisher decided not to bump its value (I for one would not change the order of entries without changing updated, but that's not to say others won't). From owner-atom-syntax@mail.imc.org Mon Jan 24 22:24: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 WAA05156 for ; Mon, 24 Jan 2005 22:24: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 j0P2umCV012121; Mon, 24 Jan 2005 18:56: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 j0P2umwG012120; Mon, 24 Jan 2005 18:56: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 j0P2umjI012107; Mon, 24 Jan 2005 18:56: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 1CtGso-0001Oq-E2; Tue, 25 Jan 2005 02:56:46 +0000 Message-ID: <41F5B56D.4000706@franklinmint.fm> Date: Mon, 24 Jan 2005 21:56:45 -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: Graham , Atom WG Subject: Re: The probably-last gang of issues 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: > > At 1:45 AM +0000 1/25/05, Graham wrote: > >> 2. The Pace process doesn't encourage proposing minor (editorial, >> style, etc) changes. > > > Fully agree. > -05 is almost done right now. All valid -04 documents are valid -05 documents. Many editorial suggestions have been incorporated. I suspect Graham will prefer it. We can pick up the pace to incorporate wording and nitpick changes. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Jan 24 22:29: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 WAA05427 for ; Mon, 24 Jan 2005 22:29: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 j0P346dM012962; Mon, 24 Jan 2005 19:04: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 j0P346Aa012961; Mon, 24 Jan 2005 19:04: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 j0P346FQ012951 for ; Mon, 24 Jan 2005 19:04: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 <2005012503040001600hkunbe>; Tue, 25 Jan 2005 03:04:00 +0000 Date: Mon, 24 Jan 2005 20:03:56 -0700 Subject: Re: PacePersonLinks status 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 Monday, January 24, 2005, at 06:25 PM, Eric Scheid wrote: > On 25/1/05 11:17 AM, "Tim Bray" wrote: >> If there were no further discussion: Has failed to get anywhere near >> enough support to call rough consensus in previous go-arounds. -Tim > > was that failure of consensus due to pushback on the very concept of > > itself (or related @rel disharmony), or actual disagreement with the > use of > in person? > I'm in favor of the basic concept. I'm a little afraid of the list of proposed @rel values it would spawn--that people would want to be able to specifically point to too many things that are very similar to each other. I don't expect the proposal to achieve consensus. Looks like a good opportunity to float an extension and see if it gets widely adopted. From owner-atom-syntax@mail.imc.org Mon Jan 24 22:30: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 WAA05464 for ; Mon, 24 Jan 2005 22:30: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 j0P365qA013093; Mon, 24 Jan 2005 19:06: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 j0P365dV013092; Mon, 24 Jan 2005 19:06:05 -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 j0P364GW013079 for ; Mon, 24 Jan 2005 19:06:04 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (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 j0P361Ch026061; Mon, 24 Jan 2005 22:06:02 -0500 (EST) Message-ID: <41F5B799.7020702@intertwingly.net> Date: Mon, 24 Jan 2005 22:06: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: Antone Roundy CC: atom-syntax@imc.org Subject: Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS) References: <4540C0E8-6E78-11D9-BA9F-003065EA6144@geckotribe.com> In-Reply-To: <4540C0E8-6E78-11D9-BA9F-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: > > BTW, am I remembering correctly that "xml:" in "xml:lang" and "xml:base" > isn't a namespace prefix? You don't see xmlns:xml="..."--so is "xml:" > not a namespace prefix, or does it just not have to be declared? If it > IS a namespace prefix, then the above language works only if you don't > consider publishing "xml:base" and "xml:lang" to be ADDING the prefix, > since it was already there in the spec, but it may be possible to word > it better. Essentially, xml: is predeclared for you. See: http://www.w3.org/TR/1999/REC-xml-names-19990114/#nsc-NSDeclared - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Jan 24 22:34: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 WAA05586 for ; Mon, 24 Jan 2005 22:34: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 j0P38i7d013262; Mon, 24 Jan 2005 19:08: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 j0P38ipI013261; Mon, 24 Jan 2005 19:08:44 -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 j0P38hdr013253 for ; Mon, 24 Jan 2005 19:08:43 -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 <2005012503083801600hldq9e>; Tue, 25 Jan 2005 03:08:38 +0000 Date: Mon, 24 Jan 2005 20:08:36 -0700 Subject: Re: PaceEnclosuresAndPix status 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: <92798DAC-6E66-11D9-9797-000A95A51C9E@textuality.com> Message-Id: <67A6C6B4-6E7E-11D9-BA9F-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 24, 2005, at 05:18 PM, Tim Bray wrote: > If there were no further discussion: Got no -1's, seems useful, needed > for feature parity with RSS2, will likely go in absent some > objections. -Tim > -0.7. Turns into a kitchen sink by using it to point to things that are intended to be pre-fetched and presented along with the content (image, at least, though perhaps not enclosure). But given that we've failed to achieve consensus on any language to limit the range of uses of , perhaps that argument is dead. From owner-atom-syntax@mail.imc.org Mon Jan 24 23: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 XAA07793 for ; Mon, 24 Jan 2005 23:02: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 j0P3Y8rV014864; Mon, 24 Jan 2005 19:34: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 j0P3Y8oi014863; Mon, 24 Jan 2005 19:34:08 -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 j0P3Y76A014852 for ; Mon, 24 Jan 2005 19:34:07 -0800 (PST) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 25 Jan 2005 03:34:01 -0000 Received: from dsl-082-082-079-147.arcor-ip.net (EHLO helix) (82.82.79.147) by mail.gmx.net (mp009) with SMTP; 25 Jan 2005 04:34:01 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Antone Roundy Cc: atom-syntax@imc.org Subject: Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS) Date: Tue, 25 Jan 2005 04:34:44 +0100 Message-ID: <420bbe14.100485484@smtp.bjoern.hoehrmann.de> References: <1f2ed5cd0501241542760cb7a4@mail.gmail.com> <4540C0E8-6E78-11D9-BA9F-003065EA6144@geckotribe.com> In-Reply-To: <4540C0E8-6E78-11D9-BA9F-003065EA6144@geckotribe.com> 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 * Antone Roundy wrote: >BTW, am I remembering correctly that "xml:" in "xml:lang" and >"xml:base" isn't a namespace prefix? You don't see xmlns:xml="..."--so >is "xml:" not a namespace prefix, or does it just not have to be >declared? If it IS a namespace prefix, then the above language works >only if you don't consider publishing "xml:base" and "xml:lang" to be >ADDING the prefix, since it was already there in the spec, but it may >be possible to word it better. : [...] The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. It may, but need not, be declared, and must not be bound to any other namespace name. No other prefix may be bound to this namespace name. [...] -- 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 Mon Jan 24 23:02: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 XAA07811 for ; Mon, 24 Jan 2005 23:02: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 j0P3WxwW014817; Mon, 24 Jan 2005 19:32: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 j0P3Wxow014816; Mon, 24 Jan 2005 19:32: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 j0P3WwYd014803 for ; Mon, 24 Jan 2005 19:32:58 -0800 (PST) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 25 Jan 2005 03:32:52 -0000 Received: from dsl-082-082-079-147.arcor-ip.net (EHLO helix) (82.82.79.147) by mail.gmx.net (mp023) with SMTP; 25 Jan 2005 04:32:52 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Danny Ayers Cc: atom-syntax@imc.org Subject: Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS) Date: Tue, 25 Jan 2005 04:33:35 +0100 Message-ID: <420ab95c.99277718@smtp.bjoern.hoehrmann.de> References: <41F1C929.9070305@franklinmint.fm> <41F26238.9080907@dehora.net> <7EF03B50-6CA0-11D9-9797-000A95A51C9E@sun.com> <6.0.0.20.2.20050124121120.07392888@localhost> <453241F9-6E2C-11D9-9797-000A95A51C9E@sun.com> <81D98645-6E40-11D9-91F1-000A95D9FA7A@bblfish.net> <1f2ed5cd050124130336fe7224@mail.gmail.com> In-Reply-To: <1f2ed5cd050124130336fe7224@mail.gmail.com> 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 * Danny Ayers wrote: >To be inserted: >{{{ >Section 2. Atom Documents > >Atom processors MAY interpret unprefixed attribute names as their >namespace-qualified equivalents. >If they do, then all Atom attribute names MUST appear in the Atom namespace. > >}}} This does not make much sense to me, it is either not possible to write a test case for the first requirement in which case this would be an im- plementation detail which is out of scope of the specification, or it is possible to write such a test case in which case this would render Atom inconsistent with a broad range of XML technologies, e.g., for an XPath expression *[namespace-uri() = $x)]/@*[namespace-uri() = $x] where $x is the Atom namespace URI would be allowed to match. I am -1 on any proposal that allows or requires to put Atom-defined attributes on Atom elements in any namespace or process Atom documents as if they were constructed like that if you can tell the difference. -- 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 Mon Jan 24 23: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 XAA08134 for ; Mon, 24 Jan 2005 23:07: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 j0P3lDvH015725; Mon, 24 Jan 2005 19:47: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 j0P3lD0w015724; Mon, 24 Jan 2005 19:47:13 -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 j0P3lB12015694 for ; Mon, 24 Jan 2005 19:47:12 -0800 (PST) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 25 Jan 2005 03:47:05 -0000 Received: from dsl-082-082-079-147.arcor-ip.net (EHLO helix) (82.82.79.147) by mail.gmx.net (mp020) with SMTP; 25 Jan 2005 04:47:05 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Sam Ruby Cc: atom-syntax@imc.org Subject: Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS) Date: Tue, 25 Jan 2005 04:47:49 +0100 Message-ID: <420cbe87.100600718@smtp.bjoern.hoehrmann.de> References: <1f2ed5cd050124130336fe7224@mail.gmail.com> <4C2C6F48-6E52-11D9-BA9F-003065EA6144@geckotribe.com> <1f2ed5cd0501241542760cb7a4@mail.gmail.com> <41F5B079.6090003@intertwingly.net> In-Reply-To: <41F5B079.6090003@intertwingly.net> 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 * Sam Ruby wrote: >I'm a bit concerned about precedence rules (what happens if there is an >href attribute *AND* an atom:href attribute?). What makes most sense >here is for a prohibition disallowing such in any exension. I would >support such a rule. Allowing either atom:href or href is not a good idea either, you have to check for both attributes each time you access it and if having both at the same time is not allowed or causes undefined behavior, you need to avoid that, turning x.setAttributeNS(null, 'foo', 'bar'); into if (x.hasAttributeNS(null, 'foo') && x.hasAttributeNS(atom, 'foo')) { throw "..."; } else { x.removeAttributeNS(atom, 'atom'); x.setAttributeNS(null, 'foo', 'bar'); } This might not be too relevant for some Atom implementations, but if you implement Atom through SVG 1.2 + sXBL + ECMAScript, the result would not be pretty. -- 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 Jan 25 02:06: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 CAA22654 for ; Tue, 25 Jan 2005 02:06: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 j0P6pG9q047338; Mon, 24 Jan 2005 22:51: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 j0P6pGbL047337; Mon, 24 Jan 2005 22:51:16 -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 j0P6pEgq047323 for ; Mon, 24 Jan 2005 22:51:15 -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 1B86A4EFAB; Tue, 25 Jan 2005 01:51:11 -0500 (EST) Message-Id: <6.0.0.20.2.20050125143003.071dfd70@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 25 Jan 2005 14:30:51 +0900 To: Sascha Carlin , Atom-Syntax From: Martin Duerst Subject: Re: PaceSimpleLanguageTagging status In-Reply-To: <41F59A17.4050500@itst.net> References: <8521E062-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F59A17.4050500@itst.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 At 10:00 05/01/25, Sascha Carlin wrote: > >Tim Bray wrote: >> Not yet taken up by the WG, depends on the discussion that comes with this call. Same rules as all the others: there has to be a positive WG consensus that each adds to the base specification. -Tim > >+1, at least for atom:language inside the header. For elements, well, there _are_ use cases for elements in different languages, so, since it is optional, +1 again. -1, or better, -2. Inventing things like atom:language when there is xml:lang is just completely useless and superfluous. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Jan 25 02:25: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 CAA04793 for ; Tue, 25 Jan 2005 02:25: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 j0P7EOpH055797; Mon, 24 Jan 2005 23:14: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 j0P7EOrm055796; Mon, 24 Jan 2005 23:14: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.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j0P7EMWs055747 for ; Mon, 24 Jan 2005 23:14:23 -0800 (PST) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 25 Jan 2005 07:14:16 -0000 Received: from dsl-082-082-079-147.arcor-ip.net (EHLO helix) (82.82.79.147) by mail.gmx.net (mp021) with SMTP; 25 Jan 2005 08:14:16 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Martin Duerst Cc: atom-syntax@imc.org Subject: Re: PaceSimpleLanguageTagging status Date: Tue, 25 Jan 2005 08:15:00 +0100 Message-ID: <4214f058.113353609@smtp.bjoern.hoehrmann.de> References: <8521E062-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F59A17.4050500@itst.net> <6.0.0.20.2.20050125143003.071dfd70@localhost> In-Reply-To: <6.0.0.20.2.20050125143003.071dfd70@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: > >> Not yet taken up by the WG, depends on the discussion that comes with >this call. Same rules as all the others: there has to be a positive WG >consensus that each adds to the base specification. -Tim > > > >+1, at least for atom:language inside the header. For elements, well, >there _are_ use cases for elements in different languages, so, since it is >optional, +1 again. > >-1, or better, -2. Inventing things like atom:language when there >is xml:lang is just completely useless and superfluous. Could you clarify how xml:lang solves the problems stated in the Pace? The alternatives to the Pace would seem to be either restrict xml:lang to specific elements or implementations that lose xml:lang information or, in an authoring scenario, do not allow to use it -- i.e., ignoring the problem in the specification. Neither of which is really helped by xml:lang, so your comment seems a bit weird. -- 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 Jan 25 03:15: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 DAA08118 for ; Tue, 25 Jan 2005 03:15: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 j0P80FcO072252; Tue, 25 Jan 2005 00:00: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 j0P80FD9072250; Tue, 25 Jan 2005 00:00:15 -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 j0P80ASw072201 for ; Tue, 25 Jan 2005 00:00:10 -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 j0P805qr001676; Tue, 25 Jan 2005 03:00:06 -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 CKU96215; Tue, 25 Jan 2005 03:00:04 -0500 (EST) Message-Id: <200501250800.CKU96215@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Tim Bray'" , "'Atom Syntax'" Subject: RE: PaceSimpleLanguageTagging status Date: Tue, 25 Jan 2005 03:00:00 -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: <8521E062-6E66-11D9-9797-000A95A51C9E@textuality.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUCgL0BeY2uXr0jRbmbfYbsB2f+rgAMLWrg Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I am strongly opposed to PaceSimpleLanguageTagging. Atom should not repeat the mistake made by RSS V2.0 and others in inventing new and inadequate mechanisms for language tagging. xml:lang is the appropriate means to handle language tagging. The Pace identifies some "costs" of the xml:lang mechanism. These costs are well known and have been for some time. Their itemization does not compel a "solution" or even that the costs be addressed. They are simply the well-known and inevitable costs that are associated with providing I18N support in a flexible and comprehensive manner. Individual applications will have to decide whether they are willing to support the maximum degree of flexibility provided for in the specification, however, it would be inappropriate at this point to compromise I18N support in the future due to the limitations of existing applications. Users who have issue with database systems that do not record "language" information in addition to character set should address their concerns to the vendors of the database systems -- not to the Atom Working Group. The issue of I18N has been under active discussion since at least the early 80's and we've been writing code that addressed both character set and language ever since then (think collating sequences...). It's about time that folk woke up and addressed I18N instead of trying once again to push it off as "too-hard". Just as character set is a property of any string, language needs to be a property of most strings. That's the way the real world works. bob wyman From owner-atom-syntax@mail.imc.org Tue Jan 25 03:25: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 DAA08805 for ; Tue, 25 Jan 2005 03:25: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 j0P8CRtc076574; Tue, 25 Jan 2005 00: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 j0P8CRPl076573; Tue, 25 Jan 2005 00:12:27 -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 j0P8CMVe076501 for ; Tue, 25 Jan 2005 00:12:26 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 25 Jan 2005 08:12:15 -0000 Received: from p54856E36.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.110.54) by mail.gmx.net (mp004) with SMTP; 25 Jan 2005 09:12:15 +0100 X-Authenticated: #1915285 Message-ID: <41F5FF56.7020906@gmx.de> Date: Tue, 25 Jan 2005 09:12:06 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman CC: "Roy T. Fielding" , Sam Ruby , Atom-Syntax Syntax Subject: Re: AtomPubIssuesList for 2005/01/24 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> <41F5825F.6010901@intertwingly.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 Paul Hoffman wrote: > > At 5:03 PM -0800 1/24/05, Roy T. Fielding wrote: > >> Why don't you just invent a status of "incomplete" and leave >> them off the table until completed? It doesn't make sense to >> close issues that are not resolved one way or another. > > > It does make sense this late in the process. As we said on the list, > after this set of Paces is evaluated, we believe we're ready to go to > IETF last call. We have to finish sometime, and on our milestone is a > reasonable target. Aren't you planning to do a working-group last call before that? > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Tue Jan 25 03:26: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 DAA08869 for ; Tue, 25 Jan 2005 03:26: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 j0P8HDRn078255; Tue, 25 Jan 2005 00:17: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 j0P8HD2g078254; Tue, 25 Jan 2005 00:17:13 -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 j0P8HB9o078213 for ; Tue, 25 Jan 2005 00:17:12 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 25 Jan 2005 08:17:05 -0000 Received: from p54856E36.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.110.54) by mail.gmx.net (mp023) with SMTP; 25 Jan 2005 09:17:05 +0100 X-Authenticated: #1915285 Message-ID: <41F6007B.8000008@gmx.de> Date: Tue, 25 Jan 2005 09:16:59 +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: PaceIRI status References: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.com> In-Reply-To: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.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 Tim Bray wrote: > > If there were no further discussion: It's hard to see how to avoid > adopting this now that IRIs are standards-track RFC. -Tim I saw some concerns (with which I agree) that requiring the presence of an IDN library is problematic. As far as I can tell, it's likely to be ignored by developers of clients that run on somwehat constrained devices. Also; I sypmathize with supporting IRI, but that shouldn't mean it needs to replace any usage of URIs (for instance, I also think that the introduction into XMLNS 1.1 was a mistake). So: -0. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Tue Jan 25 04:15: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 EAA12498 for ; Tue, 25 Jan 2005 04:14: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 j0P8xE2d093026; Tue, 25 Jan 2005 00:59: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 j0P8xDfT093025; Tue, 25 Jan 2005 00:59:14 -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 j0P8xCNl092991 for ; Tue, 25 Jan 2005 00:59:13 -0800 (PST) (envelope-from fora@annevankesteren.nl) Received: (qmail 23476 invoked by uid 10); 25 Jan 2005 08:59:07 -0000 Received: (vexira-qq 23456-25393270 invoked from network) 25 Jan 2005 09:59:07 +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 < >; 25 Jan 2005 08:59:07 -0000 Message-ID: <41F60A5C.1060308@annevankesteren.nl> Date: Tue, 25 Jan 2005 09:59:08 +0100 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Issues with draft-ietf-atompub-format-04 Content-Type: text/plain; charset=ISO-8859-1; 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: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * 3.1.1 "type" Attribute I was wondering how I can include MathML in Atom posts or simple SVG fragments. If there are extension mechanisms available, shouldn't 3.1.1 refer to those? * 3.5.1 "rel" Attribute Why are the only values defined "alternate" and "related"? I have implemented "via" for a long time on my personal weblog and some aggregators have even implemented support for it. I consider it to be quite useful. * 3.5.2 "type" Attribute It is a bit vague that this TYPE attribute differs from the one in section 3.1.1. Where this one MUST have a MIME type as value the other MUST NOT. * 3.5.4 "hreflang" Attribute What I do not understand is that Atom provides a mechanism for linking to translations of the entry but does not provide a mechanism to include the actual translation. (For example, by allowing only a single TITLE element instead of allowing multiple if the value of the xml:lang attribute is different.) * 4.1 "version" Attribute Does this attribute imply the feed has to be downloaded first before the aggregator knows if it supports the Atom format used? Can this not be solved by a MIME type parameter or is that going to difficult to implement? * 4.2.2 "atom:link" Element It does not make sense to only allow a single "alternate" link construct if the TYPE attribute has the same value. What if I have translations of the document in question? For example: # # * 5.2 "atom:link" Element This element has the same stupid restriction. It actually contradicts the statement made in 3.5.4. * 5.4 "atom:edit" Element Why does the specification not define that this MUST be a URI and how this URI MUST be processed as is done in for example 3.5.3? * 5.8 "atom:id" Element What type of content does this element contain? A URI, a string? How should it be created? How can I make sure, as a publisher that my atom:id value is universally unique and always will be? * 5.12.1 "type" attribute This makes the TYPE attribute suck even more, IMHO. Can the Atom WG not introduce a second attribute? I believe we had MODE and TYPE some time ago. * 5.12.2 "src" attribute How about fallback content? What is meant with "should be local"? For example, what do I do if I want to include a large SVG graphic in my feed which has the MIME type "image/svg+xml". Should I include it into the feed? This was about it. I hope it is of some use. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Tue Jan 25 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 FAA21446 for ; Tue, 25 Jan 2005 05:46: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 j0PASFOB024282; Tue, 25 Jan 2005 02: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 j0PASFv6024281; Tue, 25 Jan 2005 02:28: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.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0PASExo024246 for ; Tue, 25 Jan 2005 02:28:14 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so30475rnz for ; Tue, 25 Jan 2005 02:28: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:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=mIieCkSi4bc6iop+F2BEWj8X1okTVjDHZWKIskM8DHhTWWm0okMlZUEFpIfToAvZRCA1n2X6O4sZPtDMQym2kFhP+wGNpkYENyuPQP3Xjk/ivMmt38ubPEObwMElkxY7ICKU5zVwoZ/7cX4EiAwU7DuApegZnli8ADufDKEIdjk= Received: by 10.38.206.2 with SMTP id d2mr97965rng; Tue, 25 Jan 2005 02:28:10 -0800 (PST) Received: by 10.38.179.71 with HTTP; Tue, 25 Jan 2005 02:28:08 -0800 (PST) Message-ID: <1f2ed5cd05012502287655c79e@mail.gmail.com> Date: Tue, 25 Jan 2005 11:28:08 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Sam Ruby Subject: Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS) Cc: atom-syntax@imc.org In-Reply-To: <41F5B079.6090003@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd050124130336fe7224@mail.gmail.com> <4C2C6F48-6E52-11D9-BA9F-003065EA6144@geckotribe.com> <1f2ed5cd0501241542760cb7a4@mail.gmail.com> <41F5B079.6090003@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 24 Jan 2005 21:35:37 -0500, Sam Ruby wrote: > > Danny Ayers wrote: > > > > One thing I'm not sure about - where it currently says "Atom > > processors", perhaps that would be better as merely "Atom consumers". > > For the reasons Sam gave, we don't really want extra variability in > > what's being produced, but this still would still allow RDF-like > > consumers to interpret the feed as an RDF-like language. > > Does that make sense, or is there a case I'm missing here? > > I'm still struggling to understand what this is for. So, let me ramble > for a few minutes... > > Assuming that there will be an XSLT which maps Atom to RDF, such an XSLT > will have to map all unnamespaced attributes into something with a > namespace. The namespace of the element is a reasonable choice. I'm not sure whether it'll be a good strategy to allow no-namespace attributes in extensions - extension-creators may want to use terms from within the Atom namespace in other elements (although I guess they could use the qualified versions), and it also feels like it might complicate handling (if this wasn't allowed then 'namespace of element' would still be the rule, except that namespace would always be Atom's). I realise XSLT/GRDDL is the obvious target for this stuff, but I worry a little about thinking in terms of a particular processing model. It would be nice for example if the DTD defaults could be used as a simple Atom => RDF/XML transformation, although I doubt that's possible given the namespaced attributes situation (no-namespace attributes were deprecated in RDF/XML, not sure whether they ever got banned outright). > I'm a bit concerned about precedence rules (what happens if there is an > href attribute *AND* an atom:href attribute?). What makes most sense > here is for a prohibition disallowing such in any exension. I would > support such a rule. Yep, that makes sense. > Finally, I'm a bit concerned about round tripping - i.e., producing > valid feeds from an RDF triple store. Given that an unnamespaced > attribute and a namespaced attribute are two different things - how can > a valid feed be produced? Some fairly hardwired coding will be required to constrain the syntax down to RDF/XML of the right shape anyway, I'm assuming it would only be a tad more application code to change the attribute namespaces. It would be a little easier if Atom attributes were always namespace-qualifie (it would be a lot simpler if Atom were RDF/XML...). Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Jan 25 05:55: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 FAA22329 for ; Tue, 25 Jan 2005 05:55: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 j0PAjNF5030673; Tue, 25 Jan 2005 02: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 j0PAjNNE030671; Tue, 25 Jan 2005 02:45: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0PAjJgw030629 for ; Tue, 25 Jan 2005 02:45:21 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so31213rnz for ; Tue, 25 Jan 2005 02:45: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=fkJ726qM2oygamiqk2gImS56oYBb3TSUMAiPygVPWmOqBkJ3cCERVDAT6x6V2/u5QDOV1pRD/uB/Om9bE3+C2mNyVdYRB21UexCYIAEpDKdQKZJYu2JlqyU5TB6JqWQcwGxJrF/nH5NdUVwIP17HR2BnOhKk95nCNyitNM5YjOQ= Received: by 10.38.206.2 with SMTP id d2mr101909rng; Tue, 25 Jan 2005 02:45:16 -0800 (PST) Received: by 10.38.179.71 with HTTP; Tue, 25 Jan 2005 02:45:15 -0800 (PST) Message-ID: <1f2ed5cd0501250245754cf380@mail.gmail.com> Date: Tue, 25 Jan 2005 11:45:15 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Bjoern Hoehrmann Subject: Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS) Cc: atom-syntax@imc.org In-Reply-To: <420ab95c.99277718@smtp.bjoern.hoehrmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41F1C929.9070305@franklinmint.fm> <7EF03B50-6CA0-11D9-9797-000A95A51C9E@sun.com> <6.0.0.20.2.20050124121120.07392888@localhost> <453241F9-6E2C-11D9-9797-000A95A51C9E@sun.com> <81D98645-6E40-11D9-91F1-000A95D9FA7A@bblfish.net> <1f2ed5cd050124130336fe7224@mail.gmail.com> <420ab95c.99277718@smtp.bjoern.hoehrmann.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 25 Jan 2005 04:33:35 +0100, Bjoern Hoehrmann wrote: > * Danny Ayers wrote: > >To be inserted: > >{{{ > >Section 2. Atom Documents > > > >Atom processors MAY interpret unprefixed attribute names as their > >namespace-qualified equivalents. > >If they do, then all Atom attribute names MUST appear in the Atom namespace. > > > >}}} > > This does not make much sense to me, it is either not possible to write > a test case for the first requirement in which case this would be an im- > plementation detail which is out of scope of the specification, or it is > possible to write such a test case in which case this would render Atom > inconsistent with a broad range of XML technologies, e.g., for > > Sorry, swap in the word 'consumer'. Straight XML applications will see that exactly as written, languages that require disambiguation of 'bar' will read it as 'atom:bar' A test case would be an RDF processor seeing the triples: _:fooinstance rdf:type atom:foo . _:fooinstance atom:bar "baz" . (assuming atom:foo was a class) Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Jan 25 05:57: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 FAA22584 for ; Tue, 25 Jan 2005 05: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 j0PAmrdh031814; Tue, 25 Jan 2005 02: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 j0PAmr82031813; Tue, 25 Jan 2005 02:48: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 j0PAmrKI031779 for ; Tue, 25 Jan 2005 02:48:53 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so31380rnz for ; Tue, 25 Jan 2005 02:48: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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=RxVnkD3JGiJpIex+why1NAOQousLPJYEJAxkNYnlb9GVxbucOTkAMa5oydKfGwaPNdAN5hvAgGMU1oX/fENwBbfkKo6xqJx7+POp5kIttgZ4CpTStHXhAd0cx0UiEv5mmG8XP+MhOD6U5nUN3nZZZRnAGbWUSzsAEzz+bvFu1Ew= Received: by 10.38.206.2 with SMTP id d2mr102922rng; Tue, 25 Jan 2005 02:48:47 -0800 (PST) Received: by 10.38.179.71 with HTTP; Tue, 25 Jan 2005 02:48:47 -0800 (PST) Message-ID: <1f2ed5cd0501250248343bbf7f@mail.gmail.com> Date: Tue, 25 Jan 2005 11:48:47 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Bjoern Hoehrmann Subject: Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS) Cc: Sam Ruby , atom-syntax@imc.org In-Reply-To: <420cbe87.100600718@smtp.bjoern.hoehrmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd050124130336fe7224@mail.gmail.com> <4C2C6F48-6E52-11D9-BA9F-003065EA6144@geckotribe.com> <1f2ed5cd0501241542760cb7a4@mail.gmail.com> <41F5B079.6090003@intertwingly.net> <420cbe87.100600718@smtp.bjoern.hoehrmann.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 25 Jan 2005 04:47:49 +0100, Bjoern Hoehrmann wrote: > > * Sam Ruby wrote: > >I'm a bit concerned about precedence rules (what happens if there is an > >href attribute *AND* an atom:href attribute?). What makes most sense > >here is for a prohibition disallowing such in any exension. I would > >support such a rule. > This might not be too relevant for some Atom implementations, but if you > implement Atom through SVG 1.2 + sXBL + ECMAScript, the result would not > be pretty. Again, I don't think this a problem when the no-namespace/atom-namespace mapping is only an option for consumers - unless I'm missing something? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Jan 25 06:36: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 GAA25374 for ; Tue, 25 Jan 2005 06:36: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 j0PBLmg7044295; Tue, 25 Jan 2005 03:21: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 j0PBLmia044294; Tue, 25 Jan 2005 03:21: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 j0PBLkLC044253 for ; Tue, 25 Jan 2005 03:21:47 -0800 (PST) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 25 Jan 2005 11:21:40 -0000 Received: from dsl-213-023-059-068.arcor-ip.net (EHLO helix) (213.23.59.68) by mail.gmx.net (mp010) with SMTP; 25 Jan 2005 12:21:40 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Danny Ayers Cc: atom-syntax@imc.org Subject: Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS) Date: Tue, 25 Jan 2005 12:22:24 +0100 Message-ID: <421724ec.126813515@smtp.bjoern.hoehrmann.de> References: <7EF03B50-6CA0-11D9-9797-000A95A51C9E@sun.com> <6.0.0.20.2.20050124121120.07392888@localhost> <453241F9-6E2C-11D9-9797-000A95A51C9E@sun.com> <81D98645-6E40-11D9-91F1-000A95D9FA7A@bblfish.net> <1f2ed5cd050124130336fe7224@mail.gmail.com> <420ab95c.99277718@smtp.bjoern.hoehrmann.de> <1f2ed5cd0501250245754cf380@mail.gmail.com> In-Reply-To: <1f2ed5cd0501250245754cf380@mail.gmail.com> 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 * Danny Ayers wrote: >> This does not make much sense to me, it is either not possible to write >> a test case for the first requirement in which case this would be an im- >> plementation detail which is out of scope of the specification, or it is >> possible to write such a test case in which case this would render Atom >> inconsistent with a broad range of XML technologies, e.g., for >> >> > >Sorry, swap in the word 'consumer'. Straight XML applications will see >that exactly as written, languages that require disambiguation of >'bar' will read it as 'atom:bar' > >A test case would be an RDF processor seeing the triples: > >_:fooinstance rdf:type atom:foo . >_:fooinstance atom:bar "baz" . > >(assuming atom:foo was a class) If this implementation detail is exposed to the user, it would seem reasonable to consider such a software a Atom-to-something-else con- verter; you would thus seem to propose the introduction of conformance requirements for Atom conversion programs into the specification. No? -- 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 Jan 25 06:37: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 GAA25410 for ; Tue, 25 Jan 2005 06:37: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 j0PBN804044727; Tue, 25 Jan 2005 03:23: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 j0PBN8MR044726; Tue, 25 Jan 2005 03:23:08 -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 j0PBN7qU044685 for ; Tue, 25 Jan 2005 03:23:07 -0800 (PST) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 25 Jan 2005 11:23:01 -0000 Received: from dsl-213-023-059-068.arcor-ip.net (EHLO helix) (213.23.59.68) by mail.gmx.net (mp011) with SMTP; 25 Jan 2005 12:23:01 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Danny Ayers Cc: atom-syntax@imc.org Subject: Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS) Date: Tue, 25 Jan 2005 12:23:46 +0100 Message-ID: <42182bfb.128620531@smtp.bjoern.hoehrmann.de> References: <1f2ed5cd050124130336fe7224@mail.gmail.com> <4C2C6F48-6E52-11D9-BA9F-003065EA6144@geckotribe.com> <1f2ed5cd0501241542760cb7a4@mail.gmail.com> <41F5B079.6090003@intertwingly.net> <420cbe87.100600718@smtp.bjoern.hoehrmann.de> <1f2ed5cd0501250248343bbf7f@mail.gmail.com> In-Reply-To: <1f2ed5cd0501250248343bbf7f@mail.gmail.com> 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 * Danny Ayers wrote: >Again, I don't think this a problem when the >no-namespace/atom-namespace mapping is only an option for consumers - >unless I'm missing something? I am not sure what you consider a "consumer" in this context, pointer? -- 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 Jan 25 07:57: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 HAA00621 for ; Tue, 25 Jan 2005 07:57: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 j0PCjhKx072496; Tue, 25 Jan 2005 04: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 j0PCjgh8072495; Tue, 25 Jan 2005 04:45:42 -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 j0PCjfpP072450 for ; Tue, 25 Jan 2005 04:45:42 -0800 (PST) (envelope-from fora@annevankesteren.nl) Received: (qmail 27347 invoked by uid 10); 25 Jan 2005 12:45:36 -0000 Received: (vexira-qq 27330-57235FF9 invoked from network) 25 Jan 2005 13:45: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 < >; 25 Jan 2005 12:45:36 -0000 Message-ID: <41F63F71.5090804@annevankesteren.nl> Date: Tue, 25 Jan 2005 13:45:37 +0100 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid , atom-syntax@imc.org Subject: Re: Issues with draft-ietf-atompub-format-04 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.5; VDF: 6.29.0.52; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit (CC'ing the list.) >> * 3.1.1 "type" Attribute >> >> I was wondering how I can include MathML in Atom posts or simple >> SVG fragments. If there are extension mechanisms available, >> shouldn't 3.1.1 refer to those? > > 3.1 is Text Constructs, which are used for > > inside the element ... 4.2.1 "atom:title" Element 4.2.8 > "atom:tagline" Element 4.2.11 "atom:copyright" Element 4.2.12 > "atom:info" Element > > inside the element ... 5.1 "atom:title" Element 5.11 > "atom:summary" Element 5.13 "atom:copyright" Element > > Which of these do you want to use MathML or SVG, and why can't you > use @type="XHTML" with name spaced MathML/SVG inside that? I can see usage of MathML in atom:enntry>atom:title and perhaps even in atom:head>atom:title. atom:tagline could include a little SVG image. The problem is that the specification uses a SHOULD for validating XHTML. That is the problem. > Note that Text Constructs are not used for 5.12 "atom:content" > Elements I am aware of that although it not really clear from the specification. >> * 3.5.2 "type" Attribute >> >> It is a bit vague that this TYPE attribute differs from the one in >> section 3.1.1. Where this one MUST have a MIME type as value the >> other MUST NOT. > > agree on the name clash. 3.5.2 should be "type", but 3.1.1 should be > something else. "mode" maybe? +1 for a MODE attribute. >> * 4.1 "version" Attribute >> >> Does this attribute imply the feed has to be downloaded first >> before the aggregator knows if it supports the Atom format used? >> Can this not be solved by a MIME type parameter or is that going to >> difficult to implement? > > interesting thought -- how would that actually look, in practice? "Content-Type:application/atom+xml;version=1.1" or so. This would make it easier for aggregators to see if they need to download the whole feed. It would also make content negotiation more interesting since aggregators can claim to support a specific version of Atom, not all of them. >> * 4.2.2 "atom:link" Element >> >> It does not make sense to only allow a single "alternate" link >> construct if the TYPE attribute has the same value. What if I have >> translations of the document in question? > > agree. I've mentioned this on list a few times, I think we need a > Pace to get anyone to notice. A pace is a wiki document which proposes new wording to be included in the next specification? >> * 5.4 "atom:edit" Element >> >> Why does the specification not define that this MUST be a URI and >> how this URI MUST be processed as is done in for example 3.5.3? > > it's a Service Construct, as detailed in 3.4, and 3.4.1. does say > "whose value MUST be a URI reference" > > Maybe the editor should insert "(see section 3.4)" after any > reference of "Service Construct" (and similarly for any other > mentions of the various constructs). That would certainly be more useful and make the specification easier to read. >> * 5.12.1 "type" attribute >> >> This makes the TYPE attribute suck even more, IMHO. Can the Atom WG >> not introduce a second attribute? I believe we had MODE and TYPE >> some time ago. > > agreed again. The insanity of it all was that there were some > combinations of MODE and TYPE which were nonsensical, which is a > completely bogus reason. This would need a pace as well, I assume? >> * 5.12.2 "src" attribute >> >> How about fallback content? > > zero or one elements allowed, which is disappointing since > we can't even have alternates in different languages. Too bad. I was thinking of something as in: foo This would basically make it act the same as the OBJECT element in HTML. It probably would require a SRCTYPE attribute. >> For example, what do I do if I want to include a large SVG graphic >> in my feed which has the MIME type "image/svg+xml". Should I >> include it into the feed? > > Yes. That's what that paragraph means. Then I am in the opinion that paragraph should be changed. AFAIK SVG documents (and perhaps other XML formats that you do not really want to embed directly) can get pretty large. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Tue Jan 25 08:35: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 IAA03103 for ; Tue, 25 Jan 2005 08:35: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 j0PDKLgN084464; Tue, 25 Jan 2005 05:20: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 j0PDKL7r084463; Tue, 25 Jan 2005 05:20:21 -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 j0PDKHfR084456 for ; Tue, 25 Jan 2005 05:20:17 -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 59FBE4EFC5; Tue, 25 Jan 2005 08:20:15 -0500 (EST) Message-Id: <6.0.0.20.2.20050125173750.041c9958@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 25 Jan 2005 17:42:44 +0900 To: Julian Reschke , Tim Bray From: Martin Duerst Subject: Re: PaceIRI status Cc: Atom Syntax In-Reply-To: <41F6007B.8000008@gmx.de> References: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F6007B.8000008@gmx.de> 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:16 05/01/25, Julian Reschke wrote: >Also; I sypmathize with supporting IRI, but that shouldn't mean it needs to replace any usage of URIs Every URI is an IRI by definition. So all URIs that are in use can be used with Atom without any problems even if the spec says we use IRIs. Replacement is definitely not the right term. >(for instance, I also think that the introduction into XMLNS 1.1 was a mistake). Well, I might agree that it was a mistake. Observable behavior for most implementations (in particular XSLT implementations, where you most easily can test actual namespace behavior) allows IRIs in namespaces anyway, so this could just have been a clarification to the XMLNS 1.0 spec, rather than bumping up the number. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Jan 25 08: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 IAA03203 for ; Tue, 25 Jan 2005 08: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 j0PDPCjK084789; Tue, 25 Jan 2005 05:25: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 j0PDPCLn084788; Tue, 25 Jan 2005 05:25:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cat-proof.de (cat.cat-proof.de [213.239.198.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0PDPBqe084781 for ; Tue, 25 Jan 2005 05:25:11 -0800 (PST) (envelope-from sc@itst.net) Received: from [192.168.1.11] (p508173E4.dip0.t-ipconnect.de [80.129.115.228]) by cat-proof.de (Postfix) with ESMTP id 38A61340B675 for ; Tue, 25 Jan 2005 14:21:31 +0100 (CET) Message-ID: <41F648A3.4050002@itst.net> Date: Tue, 25 Jan 2005 14:24:51 +0100 From: Sascha Carlin User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: PaceDateofSubject status References: In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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 Eric Scheid wrote: > That message of yours talks about "dateline", a similar concept but one > which was discussed quite some time before DateOfSubject was proposed (July, > vs September) I could not quite see the difference between DateLine and DateOfSubject... Is there any significant difference? Regards, Sascha From owner-atom-syntax@mail.imc.org Tue Jan 25 08:38: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 IAA03251 for ; Tue, 25 Jan 2005 08:38: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 j0PDTD5h085065; Tue, 25 Jan 2005 05:29: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 j0PDTDd9085064; Tue, 25 Jan 2005 05:29:13 -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 j0PDTCGp085054 for ; Tue, 25 Jan 2005 05:29:12 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 25 Jan 2005 13:29:06 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) (217.5.201.10) by mail.gmx.net (mp008) with SMTP; 25 Jan 2005 14:29:06 +0100 X-Authenticated: #1915285 Message-ID: <41F649A0.7060706@gmx.de> Date: Tue, 25 Jan 2005 14:29:04 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Duerst CC: Tim Bray , Atom Syntax Subject: Re: PaceIRI status References: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F6007B.8000008@gmx.de> <6.0.0.20.2.20050125173750.041c9958@localhost> In-Reply-To: <6.0.0.20.2.20050125173750.041c9958@localhost> 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 Martin Duerst wrote: > At 17:16 05/01/25, Julian Reschke wrote: > > >Also; I sypmathize with supporting IRI, but that shouldn't mean it > needs to replace any usage of URIs > > Every URI is an IRI by definition. So all URIs that are in use can be > used with Atom without any problems even if the spec says we use IRIs. > Replacement is definitely not the right term. Let's disagree here. If the spec currently says "URI" and is supposed to say "IRI", we *are* replacing URI by IRI (even if every URI is an IRI). > >(for instance, I also think that the introduction into XMLNS 1.1 was a > mistake). > > Well, I might agree that it was a mistake. Observable behavior for > most implementations (in particular XSLT implementations, where you > most easily can test actual namespace behavior) allows IRIs in > namespaces anyway, so this could just have been a clarification > to the XMLNS 1.0 spec, rather than bumping up the number. The big difference here is that XMLNS uses IRIs/URIs as identifiers and only for that. However, what is an XSLT that transforms Atom content to HTML supposed to do when it encounters a IRI which isn't a legal URI? For instance, it can't put it into an HTML href attribute without producing invalid HTML. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Tue Jan 25 08: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 IAA03269 for ; Tue, 25 Jan 2005 08: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 j0PDKMhJ084479; Tue, 25 Jan 2005 05:20: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 j0PDKM3p084477; Tue, 25 Jan 2005 05:20:22 -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 j0PDKMfe084466 for ; Tue, 25 Jan 2005 05:20:22 -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 7AE0F4EFB7; Tue, 25 Jan 2005 08:20:20 -0500 (EST) Message-Id: <6.0.0.20.2.20050125182523.0721d288@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 25 Jan 2005 18:26:19 +0900 To: Bjoern Hoehrmann From: Martin Duerst Subject: Re: PaceSimpleLanguageTagging status Cc: atom-syntax@imc.org In-Reply-To: <4214f058.113353609@smtp.bjoern.hoehrmann.de> References: <8521E062-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F59A17.4050500@itst.net> <6.0.0.20.2.20050125143003.071dfd70@localhost> <4214f058.113353609@smtp.bjoern.hoehrmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; 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 Bjoern, For more details, please see my earlier message at http://www.imc.org/atom-syntax/mail-archive/msg12198.html. Please comment on the specific points mentioned there. Regards, Martin. At 16:15 05/01/25, Bjoern Hoehrmann wrote: > >* Martin Duerst wrote: >> >> Not yet taken up by the WG, depends on the discussion that comes with >>this call. Same rules as all the others: there has to be a positive WG >>consensus that each adds to the base specification. -Tim >> > >> >+1, at least for atom:language inside the header. For elements, well, >>there _are_ use cases for elements in different languages, so, since it is >>optional, +1 again. >> >>-1, or better, -2. Inventing things like atom:language when there >>is xml:lang is just completely useless and superfluous. > >Could you clarify how xml:lang solves the problems stated in the Pace? >The alternatives to the Pace would seem to be either restrict xml:lang >to specific elements or implementations that lose xml:lang information >or, in an authoring scenario, do not allow to use it -- i.e., ignoring >the problem in the specification. Neither of which is really helped by >xml:lang, so your comment seems a bit weird. >-- >Bj$B‹S(Bn H$B‹I(Brmann $B%-(B mailto:bjoern@hoehrmann.de $B%-(B http://bjoern.hoehrmann.de >Weinh. Str. 22 $B%-(B Telefon: +49(0)621/4309674 $B%-(B http://www.bjoernsworld.de >68309 Mannheim $B%-(B PGP Pub. KeyID: 0xA4357E78 $B%-(B http://www.websitedev.de/ From owner-atom-syntax@mail.imc.org Tue Jan 25 08:40: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 IAA03413 for ; Tue, 25 Jan 2005 08:40: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 j0PDJdo8084435; Tue, 25 Jan 2005 05:19: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 j0PDJdOc084434; Tue, 25 Jan 2005 05:19: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.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0PDJceK084422 for ; Tue, 25 Jan 2005 05:19:39 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so38705rnz for ; Tue, 25 Jan 2005 05:19: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=bM6zekWsT0jWoqsQrriJG6FsUKep6aWo9SPZ3BoKDKvjdfW7zM6DJqQWXG1VEcT1G9q6jNCD+dWt8GzICbQiWZmDqWJ3ZhEjlfY8RiABQNw6GEoM6WowsiOYg90bcWxbm77AUWE7QpShyfb5eGu80FS3g3XAQ0EIOhnR4526oUg= Received: by 10.38.206.2 with SMTP id d2mr151861rng; Tue, 25 Jan 2005 05:19:34 -0800 (PST) Received: by 10.38.179.71 with HTTP; Tue, 25 Jan 2005 05:19:34 -0800 (PST) Message-ID: <1f2ed5cd0501250519263ac458@mail.gmail.com> Date: Tue, 25 Jan 2005 14:19:34 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Bjoern Hoehrmann Subject: Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS) Cc: atom-syntax@imc.org In-Reply-To: <421724ec.126813515@smtp.bjoern.hoehrmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <7EF03B50-6CA0-11D9-9797-000A95A51C9E@sun.com> <453241F9-6E2C-11D9-9797-000A95A51C9E@sun.com> <81D98645-6E40-11D9-91F1-000A95D9FA7A@bblfish.net> <1f2ed5cd050124130336fe7224@mail.gmail.com> <420ab95c.99277718@smtp.bjoern.hoehrmann.de> <1f2ed5cd0501250245754cf380@mail.gmail.com> <421724ec.126813515@smtp.bjoern.hoehrmann.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 25 Jan 2005 12:22:24 +0100, Bjoern Hoehrmann wrote: > If this implementation detail is exposed to the user, it would seem > reasonable to consider such a software a Atom-to-something-else con- > verter; you would thus seem to propose the introduction of conformance > requirements for Atom conversion programs into the specification. No? Not necessarily - although I take your point, it does look very application oriented and probably impossible to test within the scope of core Atom. But because it is defining the meaning of terms in the Atom namespace (atom:type will be equivalent to type) I believe this information should go in the normative part of the core spec. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Jan 25 08:48: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 IAA04192 for ; Tue, 25 Jan 2005 08:48: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 j0PDdC0B085630; Tue, 25 Jan 2005 05:39: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 j0PDdC3h085629; Tue, 25 Jan 2005 05:39:12 -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 j0PDdBc6085614 for ; Tue, 25 Jan 2005 05:39:11 -0800 (PST) (envelope-from fora@annevankesteren.nl) Received: (qmail 1662 invoked by uid 10); 25 Jan 2005 13:39:06 -0000 Received: (vexira-qq 01647-94C394D4 invoked from network) 25 Jan 2005 14:39:05 +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 < >; 25 Jan 2005 13:39:05 -0000 Message-ID: <41F64BFB.4080700@annevankesteren.nl> Date: Tue, 25 Jan 2005 14:39:07 +0100 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: Martin Duerst , Tim Bray , Atom Syntax Subject: Re: PaceIRI status References: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F6007B.8000008@gmx.de> <6.0.0.20.2.20050125173750.041c9958@localhost> <41F649A0.7060706@gmx.de> In-Reply-To: <41F649A0.7060706@gmx.de> 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: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Julian Reschke wrote: > The big difference here is that XMLNS uses IRIs/URIs as identifiers and > only for that. However, what is an XSLT that transforms Atom content to > HTML supposed to do when it encounters a IRI which isn't a legal URI? > For instance, it can't put it into an HTML href attribute without > producing invalid HTML. I guess that is a HTML errata issue rather then an Atom issue. Atom can not make sure it is compatible with every specification out there. Perhaps we could add an informative about it although I doubt if it would be useful. Furthermore, browsers do not really support IRIs either so authors are not likely to use them in HTML context anyway. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Tue Jan 25 09:00: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 JAA04909 for ; Tue, 25 Jan 2005 09:00: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 j0PDicL7086006; Tue, 25 Jan 2005 05:44: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 j0PDicUj086005; Tue, 25 Jan 2005 05:44:38 -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 j0PDia9a085994 for ; Tue, 25 Jan 2005 05:44:37 -0800 (PST) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 25 Jan 2005 13:44:31 -0000 Received: from dsl-213-023-059-068.arcor-ip.net (EHLO helix) (213.23.59.68) by mail.gmx.net (mp019) with SMTP; 25 Jan 2005 14:44:31 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Julian Reschke Cc: atom-syntax@imc.org Subject: Re: PaceIRI status Date: Tue, 25 Jan 2005 14:45:16 +0100 Message-ID: <42194c32.136867687@smtp.bjoern.hoehrmann.de> References: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F6007B.8000008@gmx.de> <6.0.0.20.2.20050125173750.041c9958@localhost> <41F649A0.7060706@gmx.de> In-Reply-To: <41F649A0.7060706@gmx.de> 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 * Julian Reschke wrote: >The big difference here is that XMLNS uses IRIs/URIs as identifiers and >only for that. However, what is an XSLT that transforms Atom content to >HTML supposed to do when it encounters a IRI which isn't a legal URI? http://www.w3.org/TR/xslt#section-HTML-Output-Method The html output method should escape non-ASCII characters in URI attribute values using the method recommended in Section B.2.1 of the HTML 4.0 Recommendation. -- 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 Jan 25 09: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 JAA07008 for ; Tue, 25 Jan 2005 09:32: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 j0PEBLv9087905; Tue, 25 Jan 2005 06:11: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 j0PEBLGM087904; Tue, 25 Jan 2005 06:11:21 -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 j0PEBI8p087896 for ; Tue, 25 Jan 2005 06:11:19 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 25 Jan 2005 14:11:13 -0000 Received: from p50825BA1.dip0.t-ipconnect.de (EHLO [192.168.1.40]) (80.130.91.161) by mail.gmx.net (mp003) with SMTP; 25 Jan 2005 15:11:13 +0100 X-Authenticated: #1915285 Message-ID: <41F65380.7090501@gmx.de> Date: Tue, 25 Jan 2005 15:11:12 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bjoern Hoehrmann CC: atom-syntax@imc.org Subject: Re: PaceIRI status References: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F6007B.8000008@gmx.de> <6.0.0.20.2.20050125173750.041c9958@localhost> <41F649A0.7060706@gmx.de> <42194c32.136867687@smtp.bjoern.hoehrmann.de> In-Reply-To: <42194c32.136867687@smtp.bjoern.hoehrmann.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 Bjoern Hoehrmann wrote: > * Julian Reschke wrote: > >>The big difference here is that XMLNS uses IRIs/URIs as identifiers and >>only for that. However, what is an XSLT that transforms Atom content to >>HTML supposed to do when it encounters a IRI which isn't a legal URI? > > > http://www.w3.org/TR/xslt#section-HTML-Output-Method > > The html output method should escape non-ASCII characters in URI > attribute values using the method recommended in Section B.2.1 of > the HTML 4.0 Recommendation. How does that help with IDNs? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Tue Jan 25 09:42: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 JAA08119 for ; Tue, 25 Jan 2005 09:42: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 j0PEUOv0089087; Tue, 25 Jan 2005 06:30: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 j0PEUO13089086; Tue, 25 Jan 2005 06:30:24 -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 j0PEUNbT089078 for ; Tue, 25 Jan 2005 06:30:23 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 36026 messnum 2840141 invoked from network[213.94.211.166/mail2.newbay.com]); 25 Jan 2005 14:30:17 -0000 Received: from mail2.newbay.com (HELO ?192.168.213.135?) (213.94.211.166) by mail06.svc.cra.dublin.eircom.net (qp 36026) with SMTP; 25 Jan 2005 14:30:17 -0000 Message-ID: <41F657F6.2020104@dehora.net> Date: Tue, 25 Jan 2005 14:30:14 +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: PaceAttributesNamespace status References: <8E003BC2-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f5050124172528e37264@mail.gmail.com> In-Reply-To: <3f1451f5050124172528e37264@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 Joe Gregorio wrote: > -1 Ick. > > The only example given of a case where this may cause others problems > is RDF, and I thought we were going to have a non-normative Atom -> > RDF XSLT? Are there other cases I am unaware of? I don't think this is specific to RDF or Atom. 1. Sam mentioned precedence rules (href and atom:href). 2. It's not clear how you'd pepper atom elements with attributes (ie do we spec that you must put your extra attribs in a namespace?). 3. it's not clear whether you're allowed to do 2 (because it's not clear whether the spec keys off from a spirit of entitlement or liberty). 4. it's not clear whether atom prefixed attributes are allowed or acceptable. Is it one or the other? Both? So I'd conclude that the specification is silent on the matter of attribute prefixing doesn't make things less messy, it's somewhat messy already; specification just shines a light on that. Indicating digust doesn't make the sitaution better or worse, although an attitude along the lines of "how could I possibly care about this arcana" seems fine to me. cheers Bill From owner-atom-syntax@mail.imc.org Tue Jan 25 09:48: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 JAA08762 for ; Tue, 25 Jan 2005 09: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 j0PEbGQQ089524; Tue, 25 Jan 2005 06:37: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 j0PEbGjC089523; Tue, 25 Jan 2005 06:37:16 -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 j0PEbFQA089515 for ; Tue, 25 Jan 2005 06:37:15 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 61240 messnum 7745114 invoked from network[213.94.211.166/mail2.newbay.com]); 25 Jan 2005 14:37:09 -0000 Received: from mail2.newbay.com (HELO ?192.168.213.135?) (213.94.211.166) by mail01.svc.cra.dublin.eircom.net (qp 61240) with SMTP; 25 Jan 2005 14:37:09 -0000 Message-ID: <41F65991.4080704@dehora.net> Date: Tue, 25 Jan 2005 14:37:05 +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: PaceIRI status References: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F6007B.8000008@gmx.de> <6.0.0.20.2.20050125173750.041c9958@localhost> In-Reply-To: <6.0.0.20.2.20050125173750.041c9958@localhost> 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 Martin Duerst wrote: > > At 17:16 05/01/25, Julian Reschke wrote: > > >Also; I sypmathize with supporting IRI, but that shouldn't mean it > needs to replace any usage of URIs > > Every URI is an IRI by definition. So all URIs that are in use can be > used with Atom without any problems even if the spec says we use IRIs. > Replacement is definitely not the right term. Martin Supersetting would be the right term perhaps; that has its own issues. I'm 0 on IRIs. cheers Bill From owner-atom-syntax@mail.imc.org Tue Jan 25 09:55: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 JAA09358 for ; Tue, 25 Jan 2005 09:55: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 j0PEeWxi089692; Tue, 25 Jan 2005 06:40: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 j0PEeW2P089691; Tue, 25 Jan 2005 06:40:32 -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 j0PEeVIA089684 for ; Tue, 25 Jan 2005 06:40:31 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 77195 messnum 5058087 invoked from network[213.94.211.166/mail2.newbay.com]); 25 Jan 2005 14:40:25 -0000 Received: from mail2.newbay.com (HELO ?192.168.213.135?) (213.94.211.166) by mail04.svc.cra.dublin.eircom.net (qp 77195) with SMTP; 25 Jan 2005 14:40:25 -0000 Message-ID: <41F65A55.2040808@dehora.net> Date: Tue, 25 Jan 2005 14:40:21 +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: PaceEnclosuresAndPix status References: <92798DAC-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f505012417187d37ae78@mail.gmail.com> <08F07334-6E70-11D9-9797-000A95A51C9E@textuality.com> In-Reply-To: <08F07334-6E70-11D9-9797-000A95A51C9E@textuality.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: > Would anyone be upset if I > updated the draft to say an aspect ratio of 2 (horizontal) to 1 > (vertical)? -Tim Not me. +1 cheers Bill From owner-atom-syntax@mail.imc.org Tue Jan 25 09:56: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 JAA09377 for ; Tue, 25 Jan 2005 09: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 j0PEl48L090213; Tue, 25 Jan 2005 06:47: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 j0PEl423090212; Tue, 25 Jan 2005 06:47: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 j0PEl2lC090186 for ; Tue, 25 Jan 2005 06:47:03 -0800 (PST) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 25 Jan 2005 14:46:57 -0000 Received: from dsl-213-023-059-068.arcor-ip.net (EHLO helix) (213.23.59.68) by mail.gmx.net (mp026) with SMTP; 25 Jan 2005 15:46:57 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Julian Reschke Cc: atom-syntax@imc.org Subject: Re: PaceIRI status Date: Tue, 25 Jan 2005 15:47:41 +0100 Message-ID: <421d5ad6.140615437@smtp.bjoern.hoehrmann.de> References: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F6007B.8000008@gmx.de> <6.0.0.20.2.20050125173750.041c9958@localhost> <41F649A0.7060706@gmx.de> <42194c32.136867687@smtp.bjoern.hoehrmann.de> <41F65380.7090501@gmx.de> In-Reply-To: <41F65380.7090501@gmx.de> 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 * Julian Reschke wrote: >>>The big difference here is that XMLNS uses IRIs/URIs as identifiers and >>>only for that. However, what is an XSLT that transforms Atom content to >>>HTML supposed to do when it encounters a IRI which isn't a legal URI? >> >> http://www.w3.org/TR/xslt#section-HTML-Output-Method >> >> The html output method should escape non-ASCII characters in URI >> attribute values using the method recommended in Section B.2.1 of >> the HTML 4.0 Recommendation. > >How does that help with IDNs? After applying the algorithm, how is the situation different from the current draft-ietf-atompub-format-04.txt draft which refers to RFC2396bis? -- 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 Jan 25 10:03: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 KAA09668 for ; Tue, 25 Jan 2005 10:03: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 j0PEpMt6090532; Tue, 25 Jan 2005 06:51: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 j0PEpMMJ090531; Tue, 25 Jan 2005 06:51:22 -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 j0PEpI8H090523 for ; Tue, 25 Jan 2005 06:51:18 -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 30D4B4EFC5; Tue, 25 Jan 2005 09:51:15 -0500 (EST) Message-Id: <6.0.0.20.2.20050125223715.041e2958@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 25 Jan 2005 23:47:02 +0900 To: Julian Reschke From: Martin Duerst Subject: Re: PaceIRI status Cc: Tim Bray , Atom Syntax In-Reply-To: <41F649A0.7060706@gmx.de> References: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F6007B.8000008@gmx.de> <6.0.0.20.2.20050125173750.041c9958@localhost> <41F649A0.7060706@gmx.de> 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 22:29 05/01/25, Julian Reschke wrote: >The big difference here is that XMLNS uses IRIs/URIs as identifiers and only for that. However, what is an XSLT that transforms Atom content to HTML supposed to do when it encounters a IRI which isn't a legal URI? For instance, it can't put it into an HTML href attribute without producing invalid HTML. First, the Atom spec just says that HTML or XHTML goes into certain elements, it leaves it to other specs to say what HTML or XHTML is. So Atom doesn't deal with the question of whether IRIs are allowed there or not, and I hope PaceIRI is worded correctly in that respect. Second, HTML href attributes are defined as CDATA, so in terms of validity, any Unicode character goes anyway. Third, the HTML 4 recommendation, dating back to 1997 (http://www.w3.org/TR/REC-html40-971218/appendix/notes.html#h-B.2) contains language that in today's terms amounts to saying "browsers should treat URIs with non-ASCII characters as IRIs, even though strictly speaking, they're illegal". Many browsers to some extent already do, and when the IRI RFC gets out, I guess some more will. Forth, when IRIs work, people, especially in regions that don't use the Latin script, will just expect them to work, and tools will just have to support them, so things will just develop naturally. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Jan 25 10:04: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 KAA09739 for ; Tue, 25 Jan 2005 10:04: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 j0PErpDo090709; Tue, 25 Jan 2005 06:53: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 j0PErpco090708; Tue, 25 Jan 2005 06:53:51 -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 j0PEroBe090697 for ; Tue, 25 Jan 2005 06:53:51 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 25 Jan 2005 14:53:44 -0000 Received: from p50825BA1.dip0.t-ipconnect.de (EHLO [192.168.1.40]) (80.130.91.161) by mail.gmx.net (mp006) with SMTP; 25 Jan 2005 15:53:44 +0100 X-Authenticated: #1915285 Message-ID: <41F65D77.6060701@gmx.de> Date: Tue, 25 Jan 2005 15:53:43 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bjoern Hoehrmann CC: atom-syntax@imc.org Subject: Re: PaceIRI status References: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F6007B.8000008@gmx.de> <6.0.0.20.2.20050125173750.041c9958@localhost> <41F649A0.7060706@gmx.de> <42194c32.136867687@smtp.bjoern.hoehrmann.de> <41F65380.7090501@gmx.de> <421d5ad6.140615437@smtp.bjoern.hoehrmann.de> In-Reply-To: <421d5ad6.140615437@smtp.bjoern.hoehrmann.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 Bjoern Hoehrmann wrote: > * Julian Reschke wrote: > >>>>The big difference here is that XMLNS uses IRIs/URIs as identifiers and >>>>only for that. However, what is an XSLT that transforms Atom content to >>>>HTML supposed to do when it encounters a IRI which isn't a legal URI? >>> >>>http://www.w3.org/TR/xslt#section-HTML-Output-Method >>> >>> The html output method should escape non-ASCII characters in URI >>> attribute values using the method recommended in Section B.2.1 of >>> the HTML 4.0 Recommendation. >> >>How does that help with IDNs? > > > After applying the algorithm, how is the situation different from > the current draft-ietf-atompub-format-04.txt draft which refers to > RFC2396bis? If an Atom document contains a URI, it by definition does not contain non-ASCII characters, such as no conversion is needed. Basically, the XSLT would consume a URI and be able to copy it verbatim to the output. Am I missing something? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Tue Jan 25 10:11: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 KAA10383 for ; Tue, 25 Jan 2005 10:11: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 j0PExkml091171; Tue, 25 Jan 2005 06:59: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 j0PExkXg091170; Tue, 25 Jan 2005 06:59:46 -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 j0PExiP1091160 for ; Tue, 25 Jan 2005 06:59:45 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 25 Jan 2005 14:59:39 -0000 Received: from p50825BA1.dip0.t-ipconnect.de (EHLO [192.168.1.40]) (80.130.91.161) by mail.gmx.net (mp022) with SMTP; 25 Jan 2005 15:59:39 +0100 X-Authenticated: #1915285 Message-ID: <41F65ED9.1020709@gmx.de> Date: Tue, 25 Jan 2005 15:59:37 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Duerst CC: Tim Bray , Atom Syntax Subject: Re: PaceIRI status References: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F6007B.8000008@gmx.de> <6.0.0.20.2.20050125173750.041c9958@localhost> <41F649A0.7060706@gmx.de> <6.0.0.20.2.20050125223715.041e2958@localhost> In-Reply-To: <6.0.0.20.2.20050125223715.041e2958@localhost> 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 Martin Duerst wrote: > At 22:29 05/01/25, Julian Reschke wrote: > > >The big difference here is that XMLNS uses IRIs/URIs as identifiers > and only for that. However, what is an XSLT that transforms Atom content > to HTML supposed to do when it encounters a IRI which isn't a legal URI? > For instance, it can't put it into an HTML href attribute without > producing invalid HTML. > > First, the Atom spec just says that HTML or XHTML goes into certain > elements, it leaves it to other specs to say what HTML or XHTML is. > So Atom doesn't deal with the question of whether IRIs are allowed > there or not, and I hope PaceIRI is worded correctly in that respect. > > Second, HTML href attributes are defined as CDATA, so in terms of > validity, any Unicode character goes anyway. As far as I can tell, HTML 4.01 normatively refers to RFC2396, which doesn't allow non-ASCII characters. The *DTD* may allow any kind of string here, but the spec text doesn't. > Third, the HTML 4 recommendation, dating back to 1997 > (http://www.w3.org/TR/REC-html40-971218/appendix/notes.html#h-B.2) > contains language that in today's terms amounts to saying > "browsers should treat URIs with non-ASCII characters as IRIs, > even though strictly speaking, they're illegal". Many browsers > to some extent already do, and when the IRI RFC gets out, I guess > some more will. So are there plans to add an erratum to HTML 4.01? And what's the situation for XHTML? > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Tue Jan 25 10:16: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 KAA10894 for ; Tue, 25 Jan 2005 10:16: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 j0PF7A85091671; Tue, 25 Jan 2005 07:07: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 j0PF7A0o091670; Tue, 25 Jan 2005 07:07: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-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 j0PF79gK091663 for ; Tue, 25 Jan 2005 07:07:09 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (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 j0PF73Kj019085; Tue, 25 Jan 2005 10:07:04 -0500 (EST) Message-ID: <41F66099.4080708@intertwingly.net> Date: Tue, 25 Jan 2005 10:07: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: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: Atom Syntax Subject: Re: PaceAttributesNamespace status References: <8E003BC2-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f5050124172528e37264@mail.gmail.com> <41F657F6.2020104@dehora.net> In-Reply-To: <41F657F6.2020104@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: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > > Joe Gregorio wrote: > >> -1 Ick. >> >> The only example given of a case where this may cause others problems >> is RDF, and I thought we were going to have a non-normative Atom -> >> RDF XSLT? Are there other cases I am unaware of? > > I don't think this is specific to RDF or Atom. > > 1. Sam mentioned precedence rules (href and atom:href). atom:href is not part of the specification. > 2. It's not clear how you'd pepper atom elements with attributes (ie do > we spec that you must put your extra attribs in a namespace?). This should be made clearer. What I would suggest (for the spec'ed XML serialization) is that adding attributes to atom elements is OK if and only if they are in a namespace other than "" or atom's. > 3. it's not clear whether you're allowed to do 2 (because it's not clear > whether the spec keys off from a spirit of entitlement or liberty). The spirit should be "must ignore". > 4. it's not clear whether atom prefixed attributes are allowed or > acceptable. Is it one or the other? Both? Such attributes are not equivalent to the spec'ed attributes, so the expectation would be that they would be ignored. I would support making this clearer per my comment to #2. > So I'd conclude that the specification is silent on the matter of > attribute prefixing doesn't make things less messy, it's somewhat messy > already; specification just shines a light on that. Indicating digust > doesn't make the sitaution better or worse, although an attitude along > the lines of "how could I possibly care about this arcana" seems fine to > me. I only see some small tweaks required (as perhaps some education on attributes to go into a separate document). - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Jan 25 10:25: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 KAA11734 for ; Tue, 25 Jan 2005 10:25: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 j0PFDEgo092053; Tue, 25 Jan 2005 07:13: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 j0PFDECH092052; Tue, 25 Jan 2005 07:13:14 -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 j0PFDDnY092045 for ; Tue, 25 Jan 2005 07:13: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 F20664EFAB; Tue, 25 Jan 2005 10:13:11 -0500 (EST) Message-Id: <6.0.0.20.2.20050126001005.0762ea98@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 26 Jan 2005 00:13:08 +0900 To: Julian Reschke From: Martin Duerst Subject: Re: PaceIRI status Cc: Tim Bray , Atom Syntax In-Reply-To: <41F65ED9.1020709@gmx.de> References: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F6007B.8000008@gmx.de> <6.0.0.20.2.20050125173750.041c9958@localhost> <41F649A0.7060706@gmx.de> <6.0.0.20.2.20050125223715.041e2958@localhost> <41F65ED9.1020709@gmx.de> 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 23:59 05/01/25, Julian Reschke wrote: >Martin Duerst wrote: >> At 22:29 05/01/25, Julian Reschke wrote: >> >The big difference here is that XMLNS uses IRIs/URIs as identifiers and only for that. However, what is an XSLT that transforms Atom content to HTML supposed to do when it encounters a IRI which isn't a legal URI? For instance, it can't put it into an HTML href attribute without producing invalid HTML. >> First, the Atom spec just says that HTML or XHTML goes into certain >> elements, it leaves it to other specs to say what HTML or XHTML is. >> So Atom doesn't deal with the question of whether IRIs are allowed >> there or not, and I hope PaceIRI is worded correctly in that respect. > > > > Second, HTML href attributes are defined as CDATA, so in terms of > > validity, any Unicode character goes anyway. > > > >As far as I can tell, HTML 4.01 normatively refers to RFC2396, which doesn't allow non-ASCII characters. The *DTD* may allow any kind of string here, but the spec text doesn't. I know. You were using 'invalid', not 'illegal'. The former is a technical term that is very strongly related to DTDs. >> Third, the HTML 4 recommendation, dating back to 1997 >> (http://www.w3.org/TR/REC-html40-971218/appendix/notes.html#h-B.2) >> contains language that in today's terms amounts to saying >> "browsers should treat URIs with non-ASCII characters as IRIs, >> even though strictly speaking, they're illegal". Many browsers >> to some extent already do, and when the IRI RFC gets out, I guess >> some more will. > >So are there plans to add an erratum to HTML 4.01? If there was a working errata process for HTML 4.01, I guess such an erratum would already have happened. >And what's the situation for XHTML? For XHTML 1.0/1.1, that's based on HTML 4..., so see above. For XHTML 2.0, that will just refer to the IRI RFC, I guess. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Jan 25 10:27: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 KAA12105 for ; Tue, 25 Jan 2005 10:27: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 j0PFGnpX092240; Tue, 25 Jan 2005 07:16: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 j0PFGntm092239; Tue, 25 Jan 2005 07:16:49 -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 j0PFGm9M092232 for ; Tue, 25 Jan 2005 07:16:49 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 75935 messnum 376145 invoked from network[213.94.211.166/mail2.newbay.com]); 25 Jan 2005 15:16:42 -0000 Received: from mail2.newbay.com (HELO ?192.168.213.135?) (213.94.211.166) by mail05.svc.cra.dublin.eircom.net (qp 75935) with SMTP; 25 Jan 2005 15:16:42 -0000 Message-ID: <41F662D7.9050209@dehora.net> Date: Tue, 25 Jan 2005 15:16: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 CC: Robert Sayre Subject: Re: PaceAttributesNamespace status References: <8E003BC2-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f5050124172528e37264@mail.gmail.com> <41F657F6.2020104@dehora.net> <41F66099.4080708@intertwingly.net> In-Reply-To: <41F66099.4080708@intertwingly.net> 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 [cc'd to Robert] Sam Ruby wrote: > > Bill de hÓra wrote: >> 1. Sam mentioned precedence rules (href and atom:href). > > > atom:href is not part of the specification. That should be made clearer ;) >> 2. It's not clear how you'd pepper atom elements with attributes (ie >> do we spec that you must put your extra attribs in a namespace?). > > This should be made clearer. What I would suggest (for the spec'ed XML > serialization) is that adding attributes to atom elements is OK if and > only if they are in a namespace other than "" or atom's. +1. It seems like all that need to be done is to constrain how others add/extend into atom elements. Rob says a 05 is looming; given that and 15 paces in play, should I wait until the 05 draft before suggesting text? cheers Bill From owner-atom-syntax@mail.imc.org Tue Jan 25 10:27: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 KAA12126 for ; Tue, 25 Jan 2005 10:27: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 j0PFGDlf092196; Tue, 25 Jan 2005 07:16: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 j0PFGC35092194; Tue, 25 Jan 2005 07:16:12 -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 j0PFGAxp092173 for ; Tue, 25 Jan 2005 07:16:10 -0800 (PST) (envelope-from fora@annevankesteren.nl) Received: (qmail 8395 invoked by uid 10); 25 Jan 2005 15:16:05 -0000 Received: (vexira-qq 08387-8CDEFC39 invoked from network) 25 Jan 2005 16:16:04 +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 < >; 25 Jan 2005 15:16:04 -0000 Message-ID: <41F662B6.7030706@annevankesteren.nl> Date: Tue, 25 Jan 2005 16:16:06 +0100 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: PaceFeedLink 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: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I like the proposal in general though I wonder why an absolute URI is required. Since aggregators already have to support xml:base it would be logical to make that a relative URI. Also, could an additional requirement be added. Namely that aggregators use the URI in |rel="self"| to check for the feed next time? -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Tue Jan 25 10:29: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 KAA12343 for ; Tue, 25 Jan 2005 10:29: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 j0PFDCNE092043; Tue, 25 Jan 2005 07:13: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 j0PFDCrE092042; Tue, 25 Jan 2005 07:13:12 -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 j0PFDBRZ092035 for ; Tue, 25 Jan 2005 07:13:11 -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 335E94EFB4; Tue, 25 Jan 2005 10:13:08 -0500 (EST) Message-Id: <6.0.0.20.2.20050125235853.071f5e68@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 26 Jan 2005 00:03:56 +0900 To: Julian Reschke , Bjoern Hoehrmann From: Martin Duerst Subject: Re: PaceIRI status Cc: atom-syntax@imc.org In-Reply-To: <41F65380.7090501@gmx.de> References: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F6007B.8000008@gmx.de> <6.0.0.20.2.20050125173750.041c9958@localhost> <41F649A0.7060706@gmx.de> <42194c32.136867687@smtp.bjoern.hoehrmann.de> <41F65380.7090501@gmx.de> 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 23:11 05/01/25, Julian Reschke wrote: > >Bjoern Hoehrmann wrote: >> http://www.w3.org/TR/xslt#section-HTML-Output-Method >> The html output method should escape non-ASCII characters in URI >> attribute values using the method recommended in Section B.2.1 of >> the HTML 4.0 Recommendation. > >How does that help with IDNs? There are two ways to look at this: a) It doesn't, because B.2.1 was written before anybody knew much about IDNs. b) It does, because rfc2396bis actually allows percent-encoding in the host name part, and defines what should happen with it. In practice, it will work on most browsers and other software that support IDNs, and it will not work on browsers,... that don't support IDNs. However, there are some browsers (Mozilla and Safari) that support IDNs but at least in some versions can't handle it if they are percent-escaped. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Jan 25 10:44: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 KAA14131 for ; Tue, 25 Jan 2005 10:44: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 j0PFWvj5093510; Tue, 25 Jan 2005 07: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 j0PFWvoa093509; Tue, 25 Jan 2005 07:32:57 -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 j0PFWu4c093480 for ; Tue, 25 Jan 2005 07:32:56 -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, 26 Jan 2005 04:33:06 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 26 Jan 2005 02:32:24 +1100 Subject: Re: PaceFeedLink From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <41F662B6.7030706@annevankesteren.nl> 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 26/1/05 2:16 AM, "Anne van Kesteren" wrote: > I like the proposal in general though I wonder why an absolute URI is > required. One of the intended uses is for when a browser downloads a feed resource to disk, and then hands that file to an atom handler application. Once that happens, the original location context is lost. > Since aggregators already have to support xml:base it would be logical > to make that a relative URI. A relative URI would only be useful if there is in fact an xml:base in effect. With no xml:base then the relative reference would be useless. We could either write some spec text for that unusual requirement, or we could write "MUST be absolute". Simplicity. e. From owner-atom-syntax@mail.imc.org Tue Jan 25 10:47: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 KAA14372 for ; Tue, 25 Jan 2005 10:47: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 j0PFdlhY093978; Tue, 25 Jan 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 j0PFdlHP093977; Tue, 25 Jan 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 smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0PFdk1f093950 for ; Tue, 25 Jan 2005 07:39:47 -0800 (PST) (envelope-from fora@annevankesteren.nl) Received: (qmail 11736 invoked by uid 10); 25 Jan 2005 15:39:41 -0000 Received: (vexira-qq 11722-487D06E3 invoked from network) 25 Jan 2005 16:39:41 +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 < >; 25 Jan 2005 15:39:41 -0000 Message-ID: <41F6683E.8000105@annevankesteren.nl> Date: Tue, 25 Jan 2005 16:39:42 +0100 From: Anne van Kesteren 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: PaceFeedLink 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.5; VDF: 6.29.0.52; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >> Since aggregators already have to support xml:base it would be >> logical to make that a relative URI. > > A relative URI would only be useful if there is in fact an xml:base > in effect. With no xml:base then the relative reference would be > useless. > > We could either write some spec text for that unusual requirement, or > we could write "MUST be absolute". Simplicity. Agreed. Then the only comment that remains is: # Also, could an additional requirement be added. Namely that # aggregators use the URI in |rel="self"| to check for the feed next # time? -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Tue Jan 25 10:51: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 KAA14693 for ; Tue, 25 Jan 2005 10:51: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 j0PFbhtJ093874; Tue, 25 Jan 2005 07:37: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 j0PFbhc0093873; Tue, 25 Jan 2005 07:37:43 -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 j0PFbeCl093867 for ; Tue, 25 Jan 2005 07:37:42 -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, 26 Jan 2005 04:38:15 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 26 Jan 2005 02:25:36 +1100 Subject: Re: PaceDateofSubject status From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <41F648A3.4050002@itst.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 26/1/05 12:24 AM, "Sascha Carlin" wrote: > Eric Scheid wrote: >> That message of yours talks about "dateline", a similar concept but one >> which was discussed quite some time before DateOfSubject was proposed (July, >> vs September) > > I could not quite see the difference between DateLine and DateOfSubject... Is > there any significant difference? dateline is the date[+place] the article was written (as different from published), and so while it would suit some of the use cases for DateOfSubject it wouldn't work for all of them. e. From owner-atom-syntax@mail.imc.org Tue Jan 25 10:54: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 KAA14854 for ; Tue, 25 Jan 2005 10:54: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 j0PFf2vH094035; Tue, 25 Jan 2005 07:41: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 j0PFf2xU094034; Tue, 25 Jan 2005 07:41:02 -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 j0PFf1Xs094022 for ; Tue, 25 Jan 2005 07:41:02 -0800 (PST) (envelope-from kier@sdf1.net) Received: from [192.168.2.111] (HSE-Toronto-ppp303783.sympatico.ca [64.231.66.49]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.sdf1.net (Postfix) with ESMTP id 67A9A31E25 for ; Tue, 25 Jan 2005 10:40:59 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v693) In-Reply-To: <92798DAC-6E66-11D9-9797-000A95A51C9E@textuality.com> References: <92798DAC-6E66-11D9-9797-000A95A51C9E@textuality.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0B614799-4533-42FD-A790-51C005A85C08@sdf1.net> Content-Transfer-Encoding: 7bit From: Ray Slakinski Subject: Re: PaceEnclosuresAndPix status Date: Tue, 25 Jan 2005 10:40:57 -0500 To: Atom Syntax X-Mailer: Apple Mail (2.693) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1 from me, I'm happy to see this added! On 24-Jan-05, at 7:18 PM, Tim Bray wrote: > If there were no further discussion: Got no -1's, seems useful, needed > for feature parity with RSS2, will likely go in absent some > objections. -Tim > [-----] Ray Slakinski GnuPG Fingerprint: C8AD 4847 2DA8 3469 079D 13F9 135D F0CF 1CFC FD03 Blog: http://ddll.sdf1.net From owner-atom-syntax@mail.imc.org Tue Jan 25 11:21: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 LAA17337 for ; Tue, 25 Jan 2005 11:20: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 j0PG0XBe096101; Tue, 25 Jan 2005 08: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 j0PG0XwL096100; Tue, 25 Jan 2005 08: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 (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0PG0WI6096084 for ; Tue, 25 Jan 2005 08: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 j0PG0Di08490 for ; Tue, 25 Jan 2005 08:00:13 -0800 (PST) Received: from [192.168.1.5] ([10.169.192.16]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id IAVR4C01.I0J for ; Tue, 25 Jan 2005 08:00:12 -0800 Message-ID: <41F66D83.3030306@aol.net> Date: Tue, 25 Jan 2005 08:02:11 -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: Atom Syntax Subject: Re: PaceFeedLink status References: <889E7EB6-6E66-11D9-9797-000A95A51C9E@textuality.com> In-Reply-To: <889E7EB6-6E66-11D9-9797-000A95A51C9E@textuality.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: > > Not yet taken up by the WG, depends on the discussion that comes with > this call. Same rules as all the others: there has to be a positive WG > consensus that each adds to the base specification. -Tim > +1. From owner-atom-syntax@mail.imc.org Tue Jan 25 12:04: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 MAA20333 for ; Tue, 25 Jan 2005 12:04: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 j0PGr3rB099566; Tue, 25 Jan 2005 08:53: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 j0PGr3te099565; Tue, 25 Jan 2005 08:53:03 -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 j0PGr23q099550 for ; Tue, 25 Jan 2005 08:53:03 -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 <0IAV00IHMTBSNM10@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 17:47:52 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IAV00138TOTS160@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 17:55:41 +0100 (CET) Date: Tue, 25 Jan 2005 17:57:16 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: Issues with draft-ietf-atompub-format-04 In-reply-to: <41F60A5C.1060308@annevankesteren.nl> To: Anne van Kesteren , atom-syntax@imc.org Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <41F60A5C.1060308@annevankesteren.nl> 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 Tue, 25 Jan 2005 09:59:08 +0100, Anne van Kesteren wrote: > This was about it. I hope it is of some use. I share all your concerns and issues and hope they will be addressed properly before the format is finalized. -- 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 Tue Jan 25 12:04: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 MAA20351 for ; Tue, 25 Jan 2005 12:04: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 j0PGleg2099273; Tue, 25 Jan 2005 08:47: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 j0PGlewj099272; Tue, 25 Jan 2005 08:47:40 -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 j0PGlcZg099262 for ; Tue, 25 Jan 2005 08:47:39 -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 <0IAV00I57T2SNJ10@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 17:42:28 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IAV001S6TFTT110@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 17:50:17 +0100 (CET) Date: Tue, 25 Jan 2005 17:51:52 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: Questions about -04 In-reply-to: <41E59C93.4050001@intertwingly.net> To: Sam Ruby 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: <873bx6x1z1.fsf@nwalsh.com> <41E59C93.4050001@intertwingly.net> 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 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. -- 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 Tue Jan 25 12:07: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 MAA20583 for ; Tue, 25 Jan 2005 12:07: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 j0PGvgqv099858; Tue, 25 Jan 2005 08:57: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 j0PGvgAr099857; Tue, 25 Jan 2005 08:57:42 -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 j0PGvd9I099840 for ; Tue, 25 Jan 2005 08:57:41 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <41F5FF56.7020906@gmx.de> 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> <41F5825F.6010901@intertwingly.net> <41F5FF56.7020906@gmx.de> Date: Tue, 25 Jan 2005 08:57:32 -0800 To: Atom WG From: Paul Hoffman Subject: Re: AtomPubIssuesList for 2005/01/24 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:12 AM +0100 1/25/05, Julian Reschke wrote: >Aren't you planning to do a working-group last call before that? We're planning to ask for editorial changes after the next draft. Those are also welcome now on the current draft. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Jan 25 12:07: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 MAA20632 for ; Tue, 25 Jan 2005 12:07: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 j0PGtgZH099725; Tue, 25 Jan 2005 08:55: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 j0PGtg0O099724; Tue, 25 Jan 2005 08:55:42 -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 j0PGtfTg099704 for ; Tue, 25 Jan 2005 08:55:41 -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 <0IAV00ILUTG7NL10@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 17:50:31 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IAV001LOTT7S160@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 17:58:20 +0100 (CET) Date: Tue, 25 Jan 2005 17:59:54 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: PaceEnclosuresAndPix status In-reply-to: <67A6C6B4-6E7E-11D9-BA9F-003065EA6144@geckotribe.com> To: Antone Roundy , atom-syntax@imc.org Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <67A6C6B4-6E7E-11D9-BA9F-003065EA6144@geckotribe.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 Mon, 24 Jan 2005 20:08:36 -0700, Antone Roundy wrote: > -0.7. Turns into a kitchen sink by using it to point to things > that are intended to be pre-fetched and presented along with the content I agree. I think we should have chosen another element name. turns out to be HTML's where just «everything goes». I don't like it, but if it has to be or nothing, I'd go with . +2 to aspect ratio or image size, though, no matter what the element is called. -- 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 Tue Jan 25 12: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 MAA20798 for ; Tue, 25 Jan 2005 12:08: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 j0PGvj91099866; Tue, 25 Jan 2005 08:57: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 j0PGvioV099865; Tue, 25 Jan 2005 08:57:45 -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 j0PGvd9G099840; Tue, 25 Jan 2005 08:57:40 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <41F6007B.8000008@gmx.de> References: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F6007B.8000008@gmx.de> Date: Tue, 25 Jan 2005 08:52:35 -0800 To: Julian Reschke , Tim Bray From: Paul Hoffman Subject: Re: PaceIRI status Cc: Atom Syntax 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:16 AM +0100 1/25/05, Julian Reschke wrote: >I saw some concerns (with which I agree) that requiring the presence >of an IDN library is problematic. As far as I can tell, it's likely >to be ignored by developers of clients that run on somwehat >constrained devices. I would like to hear more from developers whether or not they think this is a problem. (I'm asking this wearing my co-chair-looking-for-consensus hat, not my author-of-IDN-and-stringprep hat.) --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Jan 25 12:25: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 MAA21885 for ; Tue, 25 Jan 2005 12:25: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 j0PHFEwI001275; Tue, 25 Jan 2005 09:15: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 j0PHFE1K001274; Tue, 25 Jan 2005 09:15:14 -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 j0PHFD7x001260 for ; Tue, 25 Jan 2005 09:15:13 -0800 (PST) (envelope-from fora@annevankesteren.nl) Received: (qmail 7601 invoked by uid 10); 25 Jan 2005 17:15:08 -0000 Received: (vexira-qq 07593-AB62672F invoked from network) 25 Jan 2005 18:15:07 +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 < >; 25 Jan 2005 17:15:07 -0000 Message-ID: <41F67E9D.2090004@annevankesteren.nl> Date: Tue, 25 Jan 2005 18:15:09 +0100 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?QXNiasO4cm4gVWxzYmVyZw==?= CC: Antone Roundy , atom-syntax@imc.org Subject: Re: PaceEnclosuresAndPix status References: <67A6C6B4-6E7E-11D9-BA9F-003065EA6144@geckotribe.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn wrote: >> -0.7. Turns into a kitchen sink by using it to point to >> things that are intended to be pre-fetched and presented along with >> the content > > I agree. I think we should have chosen another element name. > turns out to be HTML's where just «everything goes». I don't > like it, but if it has to be or nothing, I'd go with . Agreed. It also does not make sense because the LINK is supposed to point to something. It should not be used for embedding graphics. Someone can use the graphic within TAGLINE or so I guess. Or even in TITLE. (Using TYPE now, per -04 spec. It should be MODE.) bar -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Tue Jan 25 12: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 MAA23863 for ; Tue, 25 Jan 2005 12: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 j0PHiWu3003135; Tue, 25 Jan 2005 09:44: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 j0PHiWF5003134; Tue, 25 Jan 2005 09:44:32 -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 j0PHiUIq003128 for ; Tue, 25 Jan 2005 09:44:30 -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 j0PHiSdt000990 for ; Tue, 25 Jan 2005 10:44: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 <0IAV0000BVXYZI@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 25 Jan 2005 10:44:23 -0700 (MST) Received: from [192.168.1.15] ([204.174.35.168]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAV005FXVXYUK@mail.sun.net> for atom-syntax@imc.org; Tue, 25 Jan 2005 10:44:22 -0700 (MST) Date: Tue, 25 Jan 2005 09:44:19 -0800 From: Tim Bray Subject: Re: PaceFeedLink In-reply-to: <41F6683E.8000105@annevankesteren.nl> To: Anne van Kesteren Cc: Atom Syntax , Eric Scheid 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: <41F6683E.8000105@annevankesteren.nl> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 25, 2005, at 7:39 AM, Anne van Kesteren wrote: > Agreed. Then the only comment that remains is: > > # Also, could an additional requirement be added. Namely that > # aggregators use the URI in |rel="self"| to check for the feed next > # time? -1 If I got the feed from location X, I may choose to do so again for perfectly good reasons even it says "my real location is Y". Why micromanage? -Tim From owner-atom-syntax@mail.imc.org Tue Jan 25 13:55: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 NAA27965 for ; Tue, 25 Jan 2005 13: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 j0PIjZ3o007579; Tue, 25 Jan 2005 10: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 j0PIjZ8Q007578; Tue, 25 Jan 2005 10:45:35 -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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0PIjYlq007565 for ; Tue, 25 Jan 2005 10:45:35 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so67175rnz for ; Tue, 25 Jan 2005 10:45:31 -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=I4Dj2R4an5vTZoiRcwuxURW3L06l7v0KmnBMwssV9qhxFWAFEGtK4FrO5cDO5CZUC5KtyWsgQvV2cz1oqfKOdzRcQXFVhh7L9l22beiYkuCvse1awN2KhXN/fo2D6Nyz73tjy06OX//Hafl+JeEezehIzB6PPgimdS8fdU8/yyw= Received: by 10.38.179.79 with SMTP id b79mr46507rnf; Tue, 25 Jan 2005 10:45:30 -0800 (PST) Received: by 10.38.179.71 with HTTP; Tue, 25 Jan 2005 10:45:30 -0800 (PST) Message-ID: <1f2ed5cd050125104594afd4f@mail.gmail.com> Date: Tue, 25 Jan 2005 19:45:30 +0100 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: PaceAttributesNamespace refactored 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 have withdrawn the previous suggestion and replaced it with the text suggested by Antone. Further adjustments/refinements welcome. The key idea is anchor the attribute names in the Atom namespace, reducing ambiguity. I would expect the reduction of ambiguity is desirable in a spec. This should be useful in practice when Atom is used alongside any language where terms need to be unambiguously qualified, such as RDF. It should also simplify the reuse of core attributes in extensions (again, through ambiguity reduction). Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Jan 25 14:01: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 OAA28243 for ; Tue, 25 Jan 2005 14:01: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 j0PIq2Tx008058; Tue, 25 Jan 2005 10:52: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 j0PIq2Ju008057; Tue, 25 Jan 2005 10:52: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.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0PIq1rj008043 for ; Tue, 25 Jan 2005 10:52:02 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so67888rnz for ; Tue, 25 Jan 2005 10:51: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=kXTb9lHtWB9qr+I1vvRvvaXStZOSpJKYdkEBZZ9/8a4HHZR+zYMYU4hlObDYQr8BqbE3886QzrpSb87AitBhimON/AHYBmtIyyEcFzfKr48OwaFeggJK0Anhy5uzbKyjLw0/3FN+je4UbO+46lbAsllh8B+Weq+zRNx8uKGlvWg= Received: by 10.38.179.79 with SMTP id b79mr49503rnf; Tue, 25 Jan 2005 10:51:56 -0800 (PST) Received: by 10.38.179.71 with HTTP; Tue, 25 Jan 2005 10:51:56 -0800 (PST) Message-ID: <1f2ed5cd050125105145005650@mail.gmail.com> Date: Tue, 25 Jan 2005 19:51:56 +0100 From: Danny Ayers Reply-To: Danny Ayers To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: PaceAttributesNamespace status Cc: Atom Syntax In-Reply-To: <41F657F6.2020104@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <8E003BC2-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f5050124172528e37264@mail.gmail.com> <41F657F6.2020104@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0PIq2rj008050 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 25 Jan 2005 14:30:14 +0000, Bill de hÓra wrote: > So I'd conclude that the specification is silent on the matter of > attribute prefixing doesn't make things less messy, it's somewhat messy > already; specification just shines a light on that. Indicating digust > doesn't make the sitaution better or worse, although an attitude along > the lines of "how could I possibly care about this arcana" seems fine to me. Quite. But I don't think "how could I possibly care" is a good justification for a -1. If it is, fine, I'll just sign our cats up to the list, they don't care either but are generally positive about things, so expect +1s... Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Jan 25 14:08: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 OAA28596 for ; Tue, 25 Jan 2005 14:08: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 j0PIxM3W008722; Tue, 25 Jan 2005 10:59: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 j0PIxM9g008721; Tue, 25 Jan 2005 10:59:22 -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 j0PIxLef008711 for ; Tue, 25 Jan 2005 10:59:22 -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 <0IAV00I4ZZ6BNI90@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 19:54:11 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IAV002CHZJB2Q10@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 20:02:00 +0100 (CET) Date: Tue, 25 Jan 2005 20:03:35 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: PaceDateUpdated2 status In-reply-to: To: Eric Scheid 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: 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 Tue, 25 Jan 2005 13:28:36 +1100, Eric Scheid wrote: > Did someone do a survey of what date concepts the various blog publishing > systems support? Yes: -- 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 Tue Jan 25 14:16: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 OAA29314 for ; Tue, 25 Jan 2005 14:16: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 j0PJ6YNK009084; Tue, 25 Jan 2005 11:06: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 j0PJ6Y18009083; Tue, 25 Jan 2005 11:06:34 -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 j0PJ6XkJ009063 for ; Tue, 25 Jan 2005 11:06:34 -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 <0IAV00ILYZIBNM90@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 20:01:23 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IAV002ORZVB2420@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 20:09:12 +0100 (CET) Date: Tue, 25 Jan 2005 20:10:47 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: PaceAttributesNamespace status In-reply-to: <41F66099.4080708@intertwingly.net> To: Sam Ruby , =?iso-8859-1?Q?Bill_de_h=D3ra?= 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: <8E003BC2-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f5050124172528e37264@mail.gmail.com> <41F657F6.2020104@dehora.net> <41F66099.4080708@intertwingly.net> 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 Tue, 25 Jan 2005 10:07:05 -0500, Sam Ruby wrote: >> 2. It's not clear how you'd pepper atom elements with attributes (ie do >> we spec that you must put your extra attribs in a namespace?). > > This should be made clearer. What I would suggest (for the spec'ed XML > serialization) is that adding attributes to atom elements is OK if and > only if they are in a namespace other than "" or atom's. +1. Some language describing this should go into the specification. I hope we don't need a pace to cover that. >> 4. it's not clear whether atom prefixed attributes are allowed or >> acceptable. Is it one or the other? Both? > > Such attributes are not equivalent to the spec'ed attributes, so the > expectation would be that they would be ignored. I would support making > this clearer per my comment to #2. I agree. I also think we should keep «Atom attributes» (although not in the Atom namespace) unprefixed and un-namespaced to have the format look cleaner and more readable. That doesn't mean that '"":href' is the same as 'atom:href', though. Thus, I'm -1 on this pace, but +1 on making the spec clearer about these issues. -- 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 Tue Jan 25 14: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 OAA29411 for ; Tue, 25 Jan 2005 14: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 j0PJ9ZYA009236; Tue, 25 Jan 2005 11:09: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 j0PJ9ZwT009235; Tue, 25 Jan 2005 11:09:35 -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 j0PJ9UEB009222 for ; Tue, 25 Jan 2005 11:09:30 -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 <0IAV00IL1ZN8NJ90@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 20:04:20 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IAW0017H008UXH0@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 20:12:09 +0100 (CET) Date: Tue, 25 Jan 2005 20:13:44 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: PaceEntriesAllTheWayDown status In-reply-to: <8AF8AFC2-6E66-11D9-9797-000A95A51C9E@textuality.com> To: Tim Bray 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: <8AF8AFC2-6E66-11D9-9797-000A95A51C9E@textuality.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 Mon, 24 Jan 2005 16:17:48 -0800, Tim Bray wrote: > If there were no further discussion: This is a radical change to the > document and, so far, hasn't gathered widespread enough support to make > it over the line. -Tim I haven't seen it before, but think it's a nice proposal. I don't see the big (bad) implications it has on the spec or implementations of it; if anything, it should make it easier to read the specification and parse and generate Atom documents. +1. -- 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 Tue Jan 25 14:22: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 OAA29733 for ; Tue, 25 Jan 2005 14:22: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 j0PJCkPE009416; Tue, 25 Jan 2005 11:12: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 j0PJCkb5009415; Tue, 25 Jan 2005 11:12:46 -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 j0PJCjs3009408 for ; Tue, 25 Jan 2005 11:12:46 -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 <0IAV00IQSZSNNJ90@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 20:07:35 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IAW002YY05O2Q20@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 20:15:24 +0100 (CET) Date: Tue, 25 Jan 2005 20:16:59 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: PaceExtendingAtom status In-reply-to: <89BB7AD4-6E66-11D9-9797-000A95A51C9E@textuality.com> To: Tim Bray 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: <89BB7AD4-6E66-11D9-9797-000A95A51C9E@textuality.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 Mon, 24 Jan 2005 16:17:46 -0800, Tim Bray wrote: > Absent some convincing -1s, it probably goes in. -Tim It says nothing about namespaces. Shouldn't it mention that all foreign markup should be namespaced, and that all elements within the Atom namespace that aren't understood should be ignorde? Or is that clear enough from the pace? I don' think so. Or I've misunderstood something completely. -- 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 Tue Jan 25 14: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 OAA00678 for ; Tue, 25 Jan 2005 14:38: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 j0PJPiDR010218; Tue, 25 Jan 2005 11:25: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 j0PJPii8010217; Tue, 25 Jan 2005 11:25:44 -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 j0PJPiCW010207 for ; Tue, 25 Jan 2005 11:25:44 -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 <0IAW00IM90E9NMA0@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 20:20:33 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IAW001240RAUXJ0@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 20:28:22 +0100 (CET) Date: Tue, 25 Jan 2005 20:29:58 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: PaceSyntaxGuidelines status In-reply-to: To: Tim Bray 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: <842417DD-6E66-11D9-9797-000A95A51C9E@textuality.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 Mon, 24 Jan 2005 18:08:08 -0800, Tim Bray wrote: > You know, I'd never really thought about this one, but now that I have, > I wonder why on earth we should be trying to micromanage syntax for > people we don't know writing extensions we know nothing about to solve > problems we've never heard of... I'm veering toward -1. -Tim How can guiding extension-writing people to use a defined syntax be bad? I mean, what implications can syntax have over what the extensions try to accomplish? Is it critical for any applications to have 'elementsWrittenLikeThis' instead of 'elements-written-like-this'? I came up with the guidelines because I'd like to see Atom, with extensions, look as clean and easilly readable as possible. If Atom becomes a mish-mash of different syntax «standards», it will be horrible to read, parse and generate. I'm very much open to rewriting stuff if there's anything in particular people have problems with. -- 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 Tue Jan 25 14:43: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 OAA01116 for ; Tue, 25 Jan 2005 14:43: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 j0PJV6li010621; Tue, 25 Jan 2005 11:31: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 j0PJV65m010620; Tue, 25 Jan 2005 11:31:06 -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 j0PJV5wk010611 for ; Tue, 25 Jan 2005 11:31:06 -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 <0IAW00IZ50N7NMA0@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 20:25:55 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IAW0024D1082H60@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 20:33:44 +0100 (CET) Date: Tue, 25 Jan 2005 20:35:19 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: PaceMustBeWellFormed status In-reply-to: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> To: Tim Bray Cc: Atom Syntax , Mark Pilgrim Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.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 Mon, 24 Jan 2005 16:17:40 -0800, Tim Bray wrote: > If there were no further discussion: The WG completely failed to > converge to consensus on these issues last time around. Consensus can > still be found here. -Tim I think we should do something about it, if we don't incorporate it into the specification. I like it very much. -- 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 Tue Jan 25 14:51: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 OAA01752 for ; Tue, 25 Jan 2005 14:51: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 j0PJc0g9011257; Tue, 25 Jan 2005 11:38: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 j0PJc0us011256; Tue, 25 Jan 2005 11:38: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 j0PJc0LO011248 for ; Tue, 25 Jan 2005 11:38:00 -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 1CtWVe-0006Sq-JI; Tue, 25 Jan 2005 19:37:54 +0000 Message-ID: <41F6A014.5050906@franklinmint.fm> Date: Tue, 25 Jan 2005 14:37:56 -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?Asbj=F8rn_Ulsberg?= CC: Tim Bray , Atom-Syntax Subject: Re: PaceSyntaxGuidelines status References: <842417DD-6E66-11D9-9797-000A95A51C9E@textuality.com> In-Reply-To: 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 Asbjørn Ulsberg wrote: > I came up with the guidelines because I'd like to see Atom, with > extensions, look as clean and easilly readable as possible. If Atom > becomes a mish-mash of different syntax «standards», it will be > horrible to read, parse and generate. Asbjørn, I can sympathize with the goal, but it's not appropriate to include in the spec. It's babysitting. If the mythical Implementor's Guide were to materialize, it might make a good home for this text. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Jan 25 14:53: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 OAA01911 for ; Tue, 25 Jan 2005 14:53: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 j0PJj37H011781; Tue, 25 Jan 2005 11:45: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 j0PJj3Dw011780; Tue, 25 Jan 2005 11:45:03 -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 j0PJj2So011764 for ; Tue, 25 Jan 2005 11:45:03 -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 <0IAW00IS31AGNLB0@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 20:39:52 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IAW001U31NHV2K0@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 20:47:41 +0100 (CET) Date: Tue, 25 Jan 2005 20:49:17 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: PaceSyntaxGuidelines status In-reply-to: <41F6A014.5050906@franklinmint.fm> To: Robert Sayre Cc: Tim Bray , 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: <842417DD-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F6A014.5050906@franklinmint.fm> 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 Tue, 25 Jan 2005 14:37:56 -0500, Robert Sayre wrote: > Asbjørn, I can sympathize with the goal, but it's not appropriate to > include in the spec. It's babysitting. I kind of agree. > If the mythical Implementor's Guide were to materialize, it might make a > good home for this text. Let's wait for it and see, then. I think we're facing a long time of waiting, though. -- 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 Tue Jan 25 15:09: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 PAA03221 for ; Tue, 25 Jan 2005 15:09: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 j0PJxIIG012999; Tue, 25 Jan 2005 11: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 j0PJxIRP012998; Tue, 25 Jan 2005 11:59:18 -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 j0PJxI6g012990 for ; Tue, 25 Jan 2005 11:59:18 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 17526 invoked by uid 17064); 25 Jan 2005 19:59:06 -0000 Received: from unknown (HELO [192.168.0.5]) ([83.112.140.71]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 25 Jan 2005 19:59:06 -0000 In-Reply-To: References: <8AF8AFC2-6E66-11D9-9797-000A95A51C9E@textuality.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <92F25AF2-6F0B-11D9-91F1-000A95D9FA7A@bblfish.net> Cc: "Roy T. Fielding" From: Henry Story Subject: Re: PaceEntriesAllTheWayDown status Date: Tue, 25 Jan 2005 20:59:08 +0100 To: Atom-Syntax X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0PJxI6g012993 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Are we speaking about PaceEntriesAllTheWayDown2 here? Because if we are I am still behind it, (though it may need adapting as it was written for the previous version of the spec). I also think we may get a +1 from Roy Fielding, as I think this is just step 1 of his proposal. I also think we could get a +0 from Bob Wyman, because I don't think it really affects his head in entry. Henry On 25 Jan 2005, at 20:13, Asbjørn Ulsberg wrote: > On Mon, 24 Jan 2005 16:17:48 -0800, Tim Bray > wrote: > >> If there were no further discussion: This is a radical change to the >> document and, so far, hasn't gathered widespread enough support to >> make it over the line. -Tim > > I haven't seen it before, but think it's a nice proposal. I don't see > the big (bad) implications it has on the spec or implementations of > it; if anything, it should make it easier to read the specification > and parse and generate Atom documents. +1. > > -- > 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 Tue Jan 25 15:28: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 PAA04930 for ; Tue, 25 Jan 2005 15:28: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 j0PKHNnX014076; Tue, 25 Jan 2005 12: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 j0PKHNNQ014073; Tue, 25 Jan 2005 12:17:23 -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 j0PKGdnU013924 for ; Tue, 25 Jan 2005 12:17:20 -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 34910B8 for ; Tue, 25 Jan 2005 12:15:45 -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 j0PKFfKB023278 for ; Tue, 25 Jan 2005 12:15:45 -0800 (PST) Date: Tue, 25 Jan 2005 12:33:35 -0800 From: Walter Underwood To: Atom Syntax Subject: Re: PaceMustBeWellFormed status Message-ID: <9E656C44A03320C76D0142CC@diva.verity.com> In-Reply-To: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> References: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.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 Monday, January 24, 2005 04:17:40 PM -0800 Tim Bray wrote: > > If there were no further discussion: The WG completely failed to converge to > consensus on these issues last time around. Consensus can still be found here. -Tim I'm +1 on this, and feel that it belongs in the spec. This is a constraint on the format of the feed document, and is testable. Forbidding re-parsing (6.2) is OK, and not a restatement of the XML spec. If you use a parser which isn't an XML parser, it might process the doc. This says you can't do that. I think that the rationale misstates the Pace. It says that Atom feeds must always be ASCII, but the proposal only requires that for text/xml feeds. application/xml feeds may use UTF-8, either in an encoding declaration or with a charset parameter. I would add a note that 3023 is normative, and maybe move the notes in 6.1 to an appendix. Are we sure we want "RFC 3023 or its successor" instead of "RFC 3023"? A successor could make some Atom feeds illegal without a change to the Atom spec. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Tue Jan 25 15:40: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 PAA05445 for ; Tue, 25 Jan 2005 15:40: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 j0PKUYf5015120; Tue, 25 Jan 2005 12:30: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 j0PKUY5l015119; Tue, 25 Jan 2005 12:30: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 j0PKUXYk015105 for ; Tue, 25 Jan 2005 12:30:33 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 25 Jan 2005 20:30:18 -0000 Received: from pD9FF0344.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.3.68) by mail.gmx.net (mp005) with SMTP; 25 Jan 2005 21:30:18 +0100 X-Authenticated: #1915285 Message-ID: <41F6AC57.1040609@gmx.de> Date: Tue, 25 Jan 2005 21:30:15 +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: PaceMustBeWellFormed status References: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> <9E656C44A03320C76D0142CC@diva.verity.com> In-Reply-To: <9E656C44A03320C76D0142CC@diva.verity.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 Walter Underwood wrote: > > --On Monday, January 24, 2005 04:17:40 PM -0800 Tim Bray > wrote: > >> >> If there were no further discussion: The WG completely failed to >> converge to >> consensus on these issues last time around. Consensus can still be >> found here. -Tim > > > I'm +1 on this, and feel that it belongs in the spec. This is a > constraint on the format of the feed document, and is testable. > ... +1 (if we can get consensus this time...) Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Tue Jan 25 15:44: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 PAA05682 for ; Tue, 25 Jan 2005 15:44: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 j0PKZFMG015404; Tue, 25 Jan 2005 12:35: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 j0PKZFOf015403; Tue, 25 Jan 2005 12:35:15 -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 j0PKZE0G015387 for ; Tue, 25 Jan 2005 12:35:14 -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 <0IAW00IYF3M3YS00@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 21:30:03 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IAW002RY3Z42HD0@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Tue, 25 Jan 2005 21:37:52 +0100 (CET) Date: Tue, 25 Jan 2005 21:39:28 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: PaceEntriesAllTheWayDown status In-reply-to: <92F25AF2-6F0B-11D9-91F1-000A95D9FA7A@bblfish.net> To: Henry Story 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: <8AF8AFC2-6E66-11D9-9797-000A95A51C9E@textuality.com> <92F25AF2-6F0B-11D9-91F1-000A95D9FA7A@bblfish.net> 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 Tue, 25 Jan 2005 20:59:08 +0100, Henry Story wrote: > Are we speaking about PaceEntriesAllTheWayDown2 here? I never saw PaceEntriesAllTheWayDown, but PaceEntriesAllTheWayDown2 looks good; so, yes. > Because if we are I am still behind it, (though it may need adapting as > it was written for the previous version of the spec). I also think we > may get a +1 from Roy Fielding, as I think this is just step 1 of his > proposal. Okay, cool. -- 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 Tue Jan 25 15:51: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 PAA06219 for ; Tue, 25 Jan 2005 15:51: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 j0PKdLeJ015619; Tue, 25 Jan 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 j0PKdL8O015618; Tue, 25 Jan 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 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 j0PKdKv3015611 for ; Tue, 25 Jan 2005 12:39:20 -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 1CtXT1-0007nA-VC; Tue, 25 Jan 2005 20:39:16 +0000 Message-ID: <41F6AE71.7060905@franklinmint.fm> Date: Tue, 25 Jan 2005 15:39:13 -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 Subject: Re: PaceMustBeWellFormed status References: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> <9E656C44A03320C76D0142CC@diva.verity.com> In-Reply-To: <9E656C44A03320C76D0142CC@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: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Walter Underwood wrote: > > --On Monday, January 24, 2005 04:17:40 PM -0800 Tim Bray > wrote: > >> >> If there were no further discussion: The WG completely failed to >> converge to >> consensus on these issues last time around. Consensus can still be >> found here. -Tim > > > I'm +1 on this, and feel that it belongs in the spec. This is a > constraint on the format of the feed document, and is testable. > > I would add a note that 3023 is normative, and maybe move the > notes in 6.1 to an appendix. I'm very -1 on this, since it makes the definition of the Atom format an HTTP message, rather than an XML document. On top of that, most of the Pace is babysitting. To the Guide with it. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Jan 25 16:00: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 QAA07149 for ; Tue, 25 Jan 2005 16:00: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 j0PKnh8U016368; Tue, 25 Jan 2005 12:49: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 j0PKnhl1016367; Tue, 25 Jan 2005 12:49:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0PKngdm016361 for ; Tue, 25 Jan 2005 12:49:43 -0800 (PST) (envelope-from lgonze@panix.com) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail3.panix.com (Postfix) with ESMTP id 244099819C for ; Tue, 25 Jan 2005 15:49:42 -0500 (EST) Received: from localhost (lgonze@localhost) by panix2.panix.com (8.11.6p3/8.8.8/PanixN1.1) with ESMTP id j0PKngZ20142 for ; Tue, 25 Jan 2005 15:49:42 -0500 (EST) Date: Tue, 25 Jan 2005 10:49:42 -1000 (HST) From: Lucas Gonze Reply-To: lucas@gonze.com To: Atom Syntax Subject: Re: PaceEnclosuresAndPix status In-Reply-To: <0B614799-4533-42FD-A790-51C005A85C08@sdf1.net> Message-ID: References: <92798DAC-6E66-11D9-9797-000A95A51C9E@textuality.com> <0B614799-4533-42FD-A790-51C005A85C08@sdf1.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A suggestion on drafting of the pace: cardinality should be stated. The idea of multiple parallel elements formatted per PaceEnclosuresAndPix was discussed with interest, and the cardinality of RSS 2.0 enclosure elements has been written up and discussed quite a lot, so the cardinality of PaceEnclosuresAndPix should be explicit. - Lucas Gonze From owner-atom-syntax@mail.imc.org Tue Jan 25 16:15: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 QAA08756 for ; Tue, 25 Jan 2005 16:15: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 j0PL6vJ8017714; Tue, 25 Jan 2005 13:06: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 j0PL6vjo017713; Tue, 25 Jan 2005 13:06:57 -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 j0PL6vU8017700 for ; Tue, 25 Jan 2005 13:06:57 -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 15224CD for ; Tue, 25 Jan 2005 13:06:52 -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 j0PL6pKB023465 for ; Tue, 25 Jan 2005 13:06:51 -0800 (PST) Date: Tue, 25 Jan 2005 13:24:45 -0800 From: Walter Underwood To: Atom Syntax Subject: Re: PaceMustBeWellFormed status Message-ID: <635613EB127E90365E12AD5C@diva.verity.com> In-Reply-To: <41F6AE71.7060905@franklinmint.fm> References: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> <9E656C44A03320C76D0142CC@diva.verity.com> <41F6AE71.7060905@franklinmint.fm> 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, January 25, 2005 03:39:13 PM -0500 Robert Sayre wrote: > > I'm very -1 on this, since it makes the definition of the Atom format > an HTTP message, rather than an XML document. > On top of that, most of the Pace is babysitting. To the Guide with it. Except that there is no implementors' guide, and this is required for interoperability. From a formal perspective, maybe it doesn't belong. >From a practical perspective, it does. It was clear from the WG discussion that this is not a well-understood area, even for experts in blog protocols. We can't assume that implementors already know RFC 3023 or even know it exists. If we assume that, we increase interop problems for Atom. It would be nice if everyone knew about RFC 3023 and did it right, but they don't. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Tue Jan 25 16:29: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 QAA11301 for ; Tue, 25 Jan 2005 16:29: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 j0PLLVWQ018555; Tue, 25 Jan 2005 13:21: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 j0PLLVwm018554; Tue, 25 Jan 2005 13:21:31 -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 j0PLLVba018548 for ; Tue, 25 Jan 2005 13:21:31 -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 1CtY7q-000066-VH; Tue, 25 Jan 2005 21:21:27 +0000 Message-ID: <41F6B859.6080103@franklinmint.fm> Date: Tue, 25 Jan 2005 16:21:29 -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 Subject: Re: PaceMustBeWellFormed status References: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> <9E656C44A03320C76D0142CC@diva.verity.com> <41F6AE71.7060905@franklinmint.fm> <635613EB127E90365E12AD5C@diva.verity.com> In-Reply-To: <635613EB127E90365E12AD5C@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: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Walter Underwood wrote: > > --On Tuesday, January 25, 2005 03:39:13 PM -0500 Robert Sayre > wrote: > >> >> I'm very -1 on this, since it makes the definition of the Atom format >> an HTTP message, rather than an XML document. >> On top of that, most of the Pace is babysitting. To the Guide with it. > > > Except that there is no implementors' guide, and this is required for > interoperability. From a formal perspective, maybe it doesn't belong. It's required for interop over HTTP. That's off-topic in the format draft, which mentions HTTP once, in passing. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Jan 25 16:53: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 QAA14329 for ; Tue, 25 Jan 2005 16:53: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 j0PLeOWq019556; Tue, 25 Jan 2005 13:40: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 j0PLeOEc019555; Tue, 25 Jan 2005 13:40:24 -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 j0PLeN0f019548 for ; Tue, 25 Jan 2005 13:40:23 -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 961BFA1 for ; Tue, 25 Jan 2005 13:40: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 j0PLeIKB023593 for ; Tue, 25 Jan 2005 13:40:18 -0800 (PST) Date: Tue, 25 Jan 2005 13:58:12 -0800 From: Walter Underwood To: Atom Syntax Subject: Re: PaceMustBeWellFormed status Message-ID: <9ED7AC6C9E0C9411A5EFEF3F@diva.verity.com> In-Reply-To: <41F6B859.6080103@franklinmint.fm> References: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> <9E656C44A03320C76D0142CC@diva.verity.com> <41F6AE71.7060905@franklinmint.fm> <635613EB127E90365E12AD5C@diva.verity.com> <41F6B859.6080103@franklinmint.fm> 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, January 25, 2005 04:21:29 PM -0500 Robert Sayre wrote: > > It's required for interop over HTTP. That's off-topic in the format draft, > which mentions HTTP once, in passing. So you suggest that we have additional format requirements in the protocol spec? The headers-ueber-alles rule in HTTP means that a legal Atom feed can become illegal when served as text/xml. That is going to suprise people and cause breakage. How about something along the wording of the XML spec's section 4.3.3: In the absence of information provided by an external transport protocol (e.g. HTTP or MIME), it is an error for ... Perhaps: An external transport protocol (e.g. HTTP with text/xml content-type) may force the document to be decoded as US-ASCII. In that case ... wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Tue Jan 25 17:49: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 RAA21720 for ; Tue, 25 Jan 2005 17:49: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 j0PMZLWq025167; Tue, 25 Jan 2005 14:35: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 j0PMZLQs025166; Tue, 25 Jan 2005 14:35: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 j0PMZLEd025160 for ; Tue, 25 Jan 2005 14:35:21 -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 1CtZHE-0000is-W7; Tue, 25 Jan 2005 22:35:13 +0000 Message-ID: <41F6C9A3.1060600@franklinmint.fm> Date: Tue, 25 Jan 2005 17:35:15 -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 Subject: Re: PaceMustBeWellFormed status References: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> <9E656C44A03320C76D0142CC@diva.verity.com> <41F6AE71.7060905@franklinmint.fm> <635613EB127E90365E12AD5C@diva.verity.com> <41F6B859.6080103@franklinmint.fm> <9ED7AC6C9E0C9411A5EFEF3F@diva.verity.com> In-Reply-To: <9ED7AC6C9E0C9411A5EFEF3F@diva.verity.com> 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: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Walter Underwood wrote: > > --On Tuesday, January 25, 2005 04:21:29 PM -0500 Robert Sayre > wrote: > >> >> It's required for interop over HTTP. That's off-topic in the format >> draft, >> which mentions HTTP once, in passing. > > > So you suggest that we have additional format requirements in the > protocol spec? I suggest saying nothing about it. I will explain why below. > The headers-ueber-alles rule in HTTP means that a legal Atom feed > can become illegal when served as text/xml. That is going to > suprise people and cause breakage. > How about something along the wording of the XML spec's section 4.3.3: > > In the absence of information provided by an external transport > protocol (e.g. HTTP or MIME), it is an error for ... > Point 1: It's already in the XML spec. This means we are targetting implementors who will understand section six, but who haven't read the XML spec. Not a set of people worth adding a whole section for. This is really just a tour of Apache's mime.types file that inserts many damaging requirements along the way. I will detail them: > 6. Client processing requirements > > Atom feeds served over HTTP MUST be well-formed XML 1.0, as defined in > Section 2.1 of the XML specification > . Furthermore, the > concept of XML well-formedness relies on first determining the > character encoding of the XML document. RFC 3023 defines how to > determine the character encoding of XML documents served over HTTP. The first sentence is redundant because all Atom feeds must be well-formed. The second sentence is plainly false. The two concepts are unrelated. > > 6.1 Determining the character encoding of an Atom feed > > The rules for determining the character encoding of an Atom feed are > the same as determining the character encoding of any XML document > served over HTTP. The rules are wholely defined by RFC 3023, but they > are summarized here because there has been widespread confusion over > how RFC 3023 should be interpreted: The text then goes on to state many requirements that are not in 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. > 2. > Publishers SHOULD serve all Atom feeds with the media type > "application/atom+xml" (registered in Section 8 of this document). > Clients MUST treat "application/atom+xml" as "application/xml" and > determine the character encoding as per RFC 3023 or its successor. Publishers should serve their documents with the MIME type they want clients to use. > 3. > 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", and clients MUST determine > the character encoding as per RFC 3023 or its successor. Publishers should serve their documents with the MIME type they want clients to use. > > 4. > 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". According to RFC 3023, XML documents served as "text/xml" > with no charset parameter have a character encoding of "us-ascii". Of course they can serve it as text/xml. They should do that if they want people to view source. It's not appropriate to send the content to an Atom processor. > > 5. > Publishers MUST NOT serve Atom feeds with a media type other than > "application/atom+xml" (registered in this Section 8 of document) or > one of the XML media types defined in RFC 3023 or its successor. In > particular, "text/plain" is never an appropriate media type for an > Atom feed. When retrieving an Atom feed served with a non-XML media > type, clients MUST reject it as non-well-formed. We have no business stating this. I will serve Atom feeds as text/plain if I want them processed as text documents. Clients shouldn't send them to the XML processor at all. Well-formedness errors come from XML processors, not passive-aggressive applications. > > 6.2 Handling well-formedness errors > > After determining the character encoding by the rules in section 6.1 > of this document, clients MUST use a conforming XML parser to parse an > Atom feed. In particular, clients MUST stop processing at the first > well-formedness error, although they MAY display any information they > have parsed before the first well-formedness error. The second sentence is incorrect, since it's acceptable for processors to continue reporting errors. > > Here is a non-comprehensive list of things clients have been known to > do after encountering a well-formedness error, which this document > specifically prohibits: > • > Clients MUST NOT reparse the feed in any other character encoding. > • > Clients MUST NOT "tidy" the feed to attempt to fix mismatched start > and end tags. > • > Clients MUST NOT guess at the meaning of undefined entities, including > entities defined in the HTML specification. We have no business making these demands, since the documents in question are not Atom documents. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Jan 25 17:54: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 RAA21962 for ; Tue, 25 Jan 2005 17:54: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 j0PMZRtp025176; Tue, 25 Jan 2005 14:35: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 j0PMZRgC025175; Tue, 25 Jan 2005 14:35:27 -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 j0PMZRIX025169 for ; Tue, 25 Jan 2005 14:35:27 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 92869 invoked by uid 17064); 25 Jan 2005 22:35:24 -0000 Received: from unknown (HELO [192.168.0.5]) ([83.112.140.97]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 25 Jan 2005 22:35:24 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <1f2ed5cd050125104594afd4f@mail.gmail.com> References: <1f2ed5cd050125104594afd4f@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <67F26D16-6F21-11D9-91F1-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: PaceAttributesNamespace refactored Date: Tue, 25 Jan 2005 23:35:25 +0100 To: Atom-Syntax Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit That looks good to me. +1 Henry Story http://bblfish.net/blog/ On 25 Jan 2005, at 19:45, Danny Ayers wrote: > I have withdrawn the previous suggestion and replaced it with the text > suggested by Antone. Further adjustments/refinements welcome. > > The key idea is anchor the attribute names in the Atom namespace, > reducing ambiguity. I would expect the reduction of ambiguity is > desirable in a spec. This should be useful in practice when Atom is > used alongside any language where terms need to be unambiguously > qualified, such as RDF. It should also simplify the reuse of core > attributes in extensions (again, through ambiguity reduction). > > Cheers, > Danny. From owner-atom-syntax@mail.imc.org Tue Jan 25 18: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 SAA25796 for ; Tue, 25 Jan 2005 18:34: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 j0PNCvgc027381; Tue, 25 Jan 2005 15:12: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 j0PNCvku027380; Tue, 25 Jan 2005 15:12:57 -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 j0PNCuMO027372 for ; Tue, 25 Jan 2005 15:12:57 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 34302 messnum 7734225 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 25 Jan 2005 23:12:51 -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 34302) with SMTP; 25 Jan 2005 23:12:51 -0000 Message-ID: <41F6D271.1070704@dehora.net> Date: Tue, 25 Jan 2005 23:12:49 +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: PaceAttributesNamespace status References: <8E003BC2-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f5050124172528e37264@mail.gmail.com> <41F657F6.2020104@dehora.net> <1f2ed5cd050125105145005650@mail.gmail.com> In-Reply-To: <1f2ed5cd050125105145005650@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, 25 Jan 2005 14:30:14 +0000, Bill de hÓra wrote: > > >>So I'd conclude that the specification is silent on the matter of >>attribute prefixing doesn't make things less messy, it's somewhat messy >>already; specification just shines a light on that. Indicating digust >>doesn't make the sitaution better or worse, although an attitude along >>the lines of "how could I possibly care about this arcana" seems fine to me. > > > Quite. But I don't think "how could I possibly care" is a good > justification for a -1. I can live with it, with respect to a deadline and 15 paces. This is not the most important thing we could be looking at and one or two sentences about how extensions should proceed can cover it off. cheers Bill From owner-atom-syntax@mail.imc.org Tue Jan 25 19:21: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 TAA29610 for ; Tue, 25 Jan 2005 19:21: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 j0Q03IHf030125; Tue, 25 Jan 2005 16:03: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 j0Q03IRG030124; Tue, 25 Jan 2005 16:03: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 j0Q03Hj7030118 for ; Tue, 25 Jan 2005 16:03: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 1CtaeP-0001J6-1e; Wed, 26 Jan 2005 00:03:13 +0000 Message-ID: <41F6DE44.8020906@franklinmint.fm> Date: Tue, 25 Jan 2005 19:03:16 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anne van Kesteren CC: atom-syntax@imc.org Subject: Re: Issues with draft-ietf-atompub-format-04 References: <41F60A5C.1060308@annevankesteren.nl> In-Reply-To: <41F60A5C.1060308@annevankesteren.nl> 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 Anne van Kesteren wrote: > > * 3.1.1 "type" Attribute > > I was wondering how I can include MathML in Atom posts or simple SVG > fragments. If there are extension mechanisms available, shouldn't 3.1.1 > refer to those? You can put it in atom:content. Other core elements are there to provide a *baseline*. > > * 3.5.1 "rel" Attribute > > Why are the only values defined "alternate" and "related"? I have > implemented "via" for a long time on my personal weblog and some > aggregators have even implemented support for it. I consider it to be > quite useful. Write a Pace. I would support it. > > * 3.5.2 "type" Attribute > > It is a bit vague that this TYPE attribute differs from the one in > section 3.1.1. Where this one MUST have a MIME type as value the other > MUST NOT. This is incorrect. > > > * 3.5.4 "hreflang" Attribute > > What I do not understand is that Atom provides a mechanism for linking > to translations of the entry but does not provide a mechanism to include > the actual translation. (For example, by allowing only a single TITLE > element instead of allowing multiple if the value of the xml:lang > attribute is different.) People are not born with Atom documents in their hands. We don't need to provide for every eventuality. > > > * 4.1 "version" Attribute > > Does this attribute imply the feed has to be downloaded first before the > aggregator knows if it supports the Atom format used? Can this not be > solved by a MIME type parameter or is that going to difficult to > implement? > I think "version" should be dropped. We can always add it later. > > * 4.2.2 "atom:link" Element > > It does not make sense to only allow a single "alternate" link construct > if the TYPE attribute has the same value. What if I have translations of > the document in question? For example: > > # > # I agree. I think we should allow one or more. > > * 5.4 "atom:edit" Element > > Why does the specification not define that this MUST be a URI and how > this URI MUST be processed as is done in for example 3.5.3? It does. See "Service Construct". > > > * 5.8 "atom:id" Element > > What type of content does this element contain? A URI, a string? How > should it be created? How can I make sure, as a publisher that my > atom:id value is universally unique and always will be? See "Identity Construct". > > > * 5.12.1 "type" attribute > > This makes the TYPE attribute suck even more, IMHO. Can the Atom WG not > introduce a second attribute? I believe we had MODE and TYPE some time > ago. > Co-constraints suck. @mode would be a multiplier on the ones we already have. > > * 5.12.2 "src" attribute > > How about fallback content? What is meant with "should be local"? For > example, what do I do if I want to include a large SVG graphic in my > feed which has the MIME type "image/svg+xml". Should I include it into > the feed? You have lots of options that don't require "fallback content". We rejected xhtml:object a long time ago. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Jan 25 20: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 UAA05669 for ; Tue, 25 Jan 2005 20:36: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 j0Q1LPMq035123; Tue, 25 Jan 2005 17:21: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 j0Q1LP1D035122; Tue, 25 Jan 2005 17:21:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (smtpout17.mailhost.ntl.com [212.250.162.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0Q1LKBj035111 for ; Tue, 25 Jan 2005 17:21:20 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta07-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050126012114.SYTA29900.mta09-winn.mailhost.ntl.com@aamta07-winn.mailhost.ntl.com>; Wed, 26 Jan 2005 01:21:14 +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 <20050126012114.RWNA3971.aamta07-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Wed, 26 Jan 2005 01:21:14 +0000 Date: Wed, 26 Jan 2005 01:20:58 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <924972221.20050126012058@djpowell.net> To: Tim Bray CC: Atom Syntax Subject: Re: PaceAttributesNamespace status In-Reply-To: <8E003BC2-6E66-11D9-9797-000A95A51C9E@textuality.com> References: <8E003BC2-6E66-11D9-9797-000A95A51C9E@textuality.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 > PaceAttributesNamespace I'm -1 on this. It seems to be authorising a RDF users to do a transform on Atom Syntax in order to make it more RDF/XML-like. If RDF users have to transform the content in order to interpret it as RDF/XML (which they do), then they might as well transform it to a decent RDF model which properly models the entities and properties involved in the feed. We don't need the format spec to authorize RDF users to do this - they can just do it. I don't think that tweaking an Atom document and interpreting it as RDF/XML is going to produce a sensible RDF model. There are also a number of technical problems: * The attribute namespace prefixing problem solved by this Pace * atom:author defaulting won't be modelled sensibly * The xml:lang and xml:base context won't be preserved by Text constructs and Extensions if they are modelled as RDF XML Literals.[1] * parseType="Resource" / parseType="Literal" needs to be assumed in certain places. If we try to solve all of these problems, then we are going to have to do a fairly complicated transformation that needs to be applied to produce a what could end up a quirky sub-optimal model. I'd rather us make sure that we have designed the format spec well enough that it has a clear model for core elements and extensions. Then the RDFers can come up with a clear well-designed RDF vocabulary for Atom and a mapping from Atom format to RDF (via XSLT?). I've just posted this as an informal proposal on the Wiki suggesting that we let an RDF mapping should be defined outside of the format specification, and that we should avoid making this impossible: http://intertwingly.net/wiki/pie/MinimalRdfProposal [1] http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/#sec-Limitations -- Dave From owner-atom-syntax@mail.imc.org Tue Jan 25 20: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 UAA05834 for ; Tue, 25 Jan 2005 20: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 j0Q1TH6u035467; Tue, 25 Jan 2005 17:29: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 j0Q1TH8f035466; Tue, 25 Jan 2005 17:29:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (smtpout17.mailhost.ntl.com [212.250.162.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0Q1TGME035455 for ; Tue, 25 Jan 2005 17:29:17 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta01-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050126012911.TUWX29900.mta09-winn.mailhost.ntl.com@aamta01-winn.mailhost.ntl.com>; Wed, 26 Jan 2005 01:29:11 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta01-winn.mailhost.ntl.com with ESMTP id <20050126012911.GLHC15415.aamta01-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Wed, 26 Jan 2005 01:29:11 +0000 Date: Wed, 26 Jan 2005 01:29:08 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <407799833.20050126012908@djpowell.net> To: "Bob Wyman" CC: "'Tim Bray'" , "'Atom Syntax'" Subject: Re: PaceSimpleLanguageTagging status In-Reply-To: <200501250800.CKU96215@ms8.netsolmail.com> References: <8521E062-6E66-11D9-9797-000A95A51C9E@textuality.com> <200501250800.CKU96215@ms8.netsolmail.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 Tuesday, January 25, 2005, 8:00:00 AM, you wrote: > I am strongly opposed to PaceSimpleLanguageTagging. I had two problems with xml:lang: One was implementation difficulty - I think that the level of language support in Atom seems a bit unbalanced. On one hand we can language tag everything anywhere - which is a good thing, but unprecedented for syndication formats; on the other hand we can only have a single title and a single alt link. Perhaps the idea is that there should be multiple feeds and language selection should be done outside Atom, eg with Accept-Language, but this doesn't seem to fit well with "xml:lang everywhere", as there isn't necessarily a language for a feed - only for the components of it. Anyway, I've heard enough arguments in favour of xml:lang that I'll accept that it is a necessary cost. My other issue was that we need to state which core elements are language sensitive and which are language neutral, otherwise implementors will guess and language tags will get lost. We also need to state what happens to extensions. I'd suggest that if we go with PaceExtensionConstruct, then Simple Extension constructs are language sensitive (although I really don't mind them being language neutral either - I'm not convinced either way). Structured Language constructs MAY be language sensitive (so if you don't know how to interpret them specifically, then you MUST preserve the language tag). So I am now -0.5 to PaceSimpleLanguageTagging, but I think that there are still some issues, so I think we need another Pace that makes it clear what xml:lang applies to. BTW: When no xml:lang is in context, is the default language be language neutral (ie: xml:lang=""), or is it determined by the envelope, eg: a HTTP Content-Language header? -- Dave From owner-atom-syntax@mail.imc.org Tue Jan 25 20: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 UAA07119 for ; Tue, 25 Jan 2005 20: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 j0Q1Z5PD035778; Tue, 25 Jan 2005 17:35: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 j0Q1Z5xD035777; Tue, 25 Jan 2005 17:35:05 -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 j0Q1Z4DY035766 for ; Tue, 25 Jan 2005 17:35:04 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta01-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050126013458.LNQZ8887.mta08-winn.mailhost.ntl.com@aamta01-winn.mailhost.ntl.com>; Wed, 26 Jan 2005 01:34:58 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta01-winn.mailhost.ntl.com with ESMTP id <20050126013458.GXMK15415.aamta01-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Wed, 26 Jan 2005 01:34:58 +0000 Date: Wed, 26 Jan 2005 01:34:55 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <5610368037.20050126013455@djpowell.net> To: Martin Duerst CC: Sascha Carlin , Atom-Syntax Subject: Re: PaceSimpleLanguageTagging status In-Reply-To: <6.0.0.20.2.20050125143003.071dfd70@localhost> References: <8521E062-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F59A17.4050500@itst.net> <6.0.0.20.2.20050125143003.071dfd70@localhost> 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, January 25, 2005, 5:30:51 AM, you wrote: > At 10:00 05/01/25, Sascha Carlin wrote: >> >>Tim Bray wrote: >>> Not yet taken up by the WG, depends on the discussion that comes with > this call. Same rules as all the others: there has to be a positive WG > consensus that each adds to the base specification. -Tim >> >>+1, at least for atom:language inside the header. For elements, well, > there _are_ use cases for elements in different languages, so, since it is > optional, +1 again. > -1, or better, -2. Inventing things like atom:language when there > is xml:lang is just completely useless and superfluous. Well, it was more like a blatantly re-badged dc:language than an invention, but I'll agree that it probably isn't the best solution. I think we should instead decide what core elements are affected by xml:lang, and whether extensions are affected. -- Dave From owner-atom-syntax@mail.imc.org Tue Jan 25 21: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 VAA08823 for ; Tue, 25 Jan 2005 21: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 j0Q22gLv037957; Tue, 25 Jan 2005 18:02: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 j0Q22gLk037956; Tue, 25 Jan 2005 18:02:42 -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 j0Q22glO037949 for ; Tue, 25 Jan 2005 18:02:42 -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 8C7174EF72; Tue, 25 Jan 2005 21:02:39 -0500 (EST) Message-Id: <6.0.0.20.2.20050126075033.076c5890@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 26 Jan 2005 08:23:00 +0900 To: Julian Reschke , Bjoern Hoehrmann From: Martin Duerst Subject: Re: PaceIRI status Cc: atom-syntax@imc.org In-Reply-To: <41F65D77.6060701@gmx.de> References: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F6007B.8000008@gmx.de> <6.0.0.20.2.20050125173750.041c9958@localhost> <41F649A0.7060706@gmx.de> <42194c32.136867687@smtp.bjoern.hoehrmann.de> <41F65380.7090501@gmx.de> <421d5ad6.140615437@smtp.bjoern.hoehrmann.de> <41F65D77.6060701@gmx.de> 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 23:53 05/01/25, Julian Reschke wrote: > >Bjoern Hoehrmann wrote: >> * Julian Reschke wrote: >> >>>>>The big difference here is that XMLNS uses IRIs/URIs as identifiers and only for that. However, what is an XSLT that transforms Atom content to HTML supposed to do when it encounters a IRI which isn't a legal URI? >>>> >>>>http://www.w3.org/TR/xslt#section-HTML-Output-Method >>>> >>>> The html output method should escape non-ASCII characters in URI >>>> attribute values using the method recommended in Section B.2.1 of >>>> the HTML 4.0 Recommendation. >>> >>>How does that help with IDNs? >> >> After applying the algorithm, how is the situation different from >> the current draft-ietf-atompub-format-04.txt draft which refers to >> RFC2396bis? > >If an Atom document contains a URI, it by definition does not contain non-ASCII characters, such as no conversion is needed. Basically, the XSLT would consume a URI and be able to copy it verbatim to the output. > >Am I missing something? Bjoern was making a vaild, but fine, point: Because we decided to refer to RFC2396bis, rather than to RFC2396, we already have bought into the fact that RFC2396bis allows percent-encoded domain names, and thus essentially requires IDN support. (apart from the basic fact that no resolver is required to resolve all URIs or IRIs) If you want to add another fine point to this, you could say that while RFC2396bis allows percent-encoded domain names, the scheme definitions, e.g. for http:,..., haven't yet been updated to allow that. I personally think that fine points are interesting, but that implementers and users won't bother too much with them if it's perfectly clear how things are supposed to work. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Jan 25 21:24: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 VAA09905 for ; Tue, 25 Jan 2005 21:24: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 j0Q22jvw037981; Tue, 25 Jan 2005 18:02: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 j0Q22jgK037980; Tue, 25 Jan 2005 18:02:45 -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 j0Q22iSU037971 for ; Tue, 25 Jan 2005 18:02:45 -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 E48294EFAB; Tue, 25 Jan 2005 21:02:42 -0500 (EST) Message-Id: <6.0.0.20.2.20050126090249.0776beb8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 26 Jan 2005 09:11:02 +0900 To: Robert Sayre , Walter Underwood From: Martin Duerst Subject: Re: PaceMustBeWellFormed status Cc: Atom Syntax In-Reply-To: <41F6C9A3.1060600@franklinmint.fm> References: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> <9E656C44A03320C76D0142CC@diva.verity.com> <41F6AE71.7060905@franklinmint.fm> <635613EB127E90365E12AD5C@diva.verity.com> <41F6B859.6080103@franklinmint.fm> <9ED7AC6C9E0C9411A5EFEF3F@diva.verity.com> <41F6C9A3.1060600@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 At 07:35 05/01/26, Robert Sayre wrote: > >Walter Underwood wrote: >> 6. Client processing requirements >> >> Atom feeds served over HTTP MUST be well-formed XML 1.0, as defined in Section 2.1 of the XML specification . Furthermore, the concept of XML well-formedness relies on first determining the character encoding of the XML document. RFC 3023 defines how to determine the character encoding of XML documents served over HTTP. > > >The first sentence is redundant because all Atom feeds must be well-formed. The second sentence is plainly false. The two concepts are unrelated. Could you explain/substantiate your claim that the second sentence is plainly false? I understand it to be true, and I have implementation experience with the W3C Markup Validator to back it up. >> 5. >> Publishers MUST NOT serve Atom feeds with a media type other than "application/atom+xml" (registered in this Section 8 of document) or one of the XML media types defined in RFC 3023 or its successor. In particular, "text/plain" is never an appropriate media type for an Atom feed. When retrieving an Atom feed served with a non-XML media type, clients MUST reject it as non-well-formed. > > >We have no business stating this. I will serve Atom feeds as text/plain if I want them processed as text documents. At which time I will claim that it's no longer an Atom feed, it just looks like one :-). The Atom spec should talk about Atom as Atom; that somebody might want to look at the Atom document as a text document, or even as a hex dump, isn't something we should be talking about. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Jan 25 21:25: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 VAA09997 for ; Tue, 25 Jan 2005 21:25: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 j0Q22qRv038017; Tue, 25 Jan 2005 18:02: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 j0Q22qKI038016; Tue, 25 Jan 2005 18:02:52 -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 j0Q22qVB038005; Tue, 25 Jan 2005 18:02:52 -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 ECC874EFCA; Tue, 25 Jan 2005 21:02:49 -0500 (EST) Message-Id: <6.0.0.20.2.20050126092953.077a70f8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 26 Jan 2005 09:45:42 +0900 To: Paul Hoffman , Julian Reschke , Tim Bray From: Martin Duerst Subject: Re: PaceIRI status Cc: Atom Syntax In-Reply-To: References: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F6007B.8000008@gmx.de> 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 01:52 05/01/26, Paul Hoffman wrote: > >At 9:16 AM +0100 1/25/05, Julian Reschke wrote: >>I saw some concerns (with which I agree) that requiring the presence of an IDN library is problematic. As far as I can tell, it's likely to be ignored by developers of clients that run on somwehat constrained devices. Just a correction to what Julian wrote: Stringprep may be ignored or partially ignored, because it requires lots of data, but I don't think the Unicode->punycode conversion will be ignored. >I would like to hear more from developers whether or not they think this is a problem. (I'm asking this wearing my co-chair-looking-for-consensus hat, not my author-of-IDN-and-stringprep hat.) Although I don't have any experience with developing blogging tools, I have some experience in integrating IDN support into a browser, and I can report on some other browsers. I hope this breaks the ice for others to chip in. 1) I have integrated IDN support into libwww, and used it in Amaya (that version isn't yet public, but it should be soon). Integrating idnkit into libwww was easy (except for the autoconf/ automake,... files, which I'm leaving to somebody else). idnkit of course includes full stringprep. 2) The maker of a widely used browser for Mobile phones has just recently announced that they support for internationalized domain names at http://www.access.co.jp/english/press/050120.html My guess is that they take some shortcuts on stringprep, but that's really just a guess. If you really need to know, I may be able to ask somebody from that company. 3) Browsers start to integrate blog support. These browsers are at the leading edge of development, and usually support IDNs already. The examples I know are Opera and Safari. IDNs will just work on those browsers, and people will come to expect them to work in other contexts. I think at least at some stage, Opera didn't implement strinprep (or not completely), but I haven't tested lately. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Jan 25 21:25: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 VAA10015 for ; Tue, 25 Jan 2005 21:25: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 j0Q22sYB038039; Tue, 25 Jan 2005 18: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 j0Q22sI3038038; Tue, 25 Jan 2005 18:02:54 -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 j0Q22sSa038032 for ; Tue, 25 Jan 2005 18:02:54 -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 C9A9F4EF72; Tue, 25 Jan 2005 21:02:52 -0500 (EST) Message-Id: <6.0.0.20.2.20050126094816.077844d0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 26 Jan 2005 09:50:53 +0900 To: Eric Scheid , Atom Syntax From: Martin Duerst Subject: Re: PaceFeedLink In-Reply-To: References: <41F662B6.7030706@annevankesteren.nl> 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:32 05/01/26, Eric Scheid wrote: > >On 26/1/05 2:16 AM, "Anne van Kesteren" wrote: >> Since aggregators already have to support xml:base it would be logical >> to make that a relative URI. > >A relative URI would only be useful if there is in fact an xml:base in >effect. With no xml:base then the relative reference would be useless. That's pretty obvious, and applies to all other links. If we want to point that out in the Atom spec, it should be done in the section that talks about xml:base. >We could either write some spec text for that unusual requirement, or we >could write "MUST be absolute". Simplicity. Again, that would apply to all other links, and would mean that we would get rid of xml:base. -1 on that from me. Treating all URIs/IRIs intended for resolution the same way is simplicity, too. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Jan 25 21: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 VAA10119 for ; Tue, 25 Jan 2005 21: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 j0Q22vH9038051; Tue, 25 Jan 2005 18: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 j0Q22vma038050; Tue, 25 Jan 2005 18:02:57 -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 j0Q22uHE038043 for ; Tue, 25 Jan 2005 18:02:56 -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 063EA4EFAB; Tue, 25 Jan 2005 21:02:54 -0500 (EST) Message-Id: <6.0.0.20.2.20050126100322.07746e30@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 26 Jan 2005 10:03:39 +0900 To: Asbj=?ISO-2022-JP?B?GyRCj1MbKEI=?=n Ulsberg , Sam Ruby From: Martin Duerst Subject: Re: Questions about -04 Cc: Atom Syntax In-Reply-To: References: <873bx6x1z1.fsf@nwalsh.com> <41E59C93.4050001@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; 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 01:51 05/01/26, Asbj$BS(Bn 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. From owner-atom-syntax@mail.imc.org Tue Jan 25 21:30: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 VAA10221 for ; Tue, 25 Jan 2005 21:30: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 j0Q28wTQ038593; Tue, 25 Jan 2005 18:08: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 j0Q28wRu038592; Tue, 25 Jan 2005 18:08:58 -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 j0Q28wZW038559 for ; Tue, 25 Jan 2005 18:08:58 -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 EBD9C18A for ; Tue, 25 Jan 2005 18:08:49 -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 j0Q28nKB024775 for ; Tue, 25 Jan 2005 18:08:49 -0800 (PST) Date: Tue, 25 Jan 2005 18:26:45 -0800 From: Walter Underwood To: "'Atom Syntax'" Subject: Re: PaceSimpleLanguageTagging status Message-ID: In-Reply-To: <407799833.20050126012908@djpowell.net> References: <8521E062-6E66-11D9-9797-000A95A51C9E@textuality.com> <200501250800.CKU96215@ms8.netsolmail.com> <407799833.20050126012908@djpowell.net> 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 Here is a middle ground. We allow xml:lang, say that it SHOULD be used at the feed and entry level, and that it MAY be used elsewhere, but be aware that the information may be lost when translated to other formats. I'm actually +1 on the original proposal, because it is a good fit to what search engines will do anyway. But I'd be +0.5 on the modified one above. wunder --On Wednesday, January 26, 2005 01:29:08 AM +0000 David Powell wrote: > > > Tuesday, January 25, 2005, 8:00:00 AM, you wrote: > > >> I am strongly opposed to PaceSimpleLanguageTagging. > > I had two problems with xml:lang: > > One was implementation difficulty - I think that the level of language > support in Atom seems a bit unbalanced. On one hand we can language > tag everything anywhere - which is a good thing, but unprecedented for > syndication formats; on the other hand we can only have a single title > and a single alt link. Perhaps the idea is that there should be > multiple feeds and language selection should be done outside Atom, eg > with Accept-Language, but this doesn't seem to fit well with "xml:lang > everywhere", as there isn't necessarily a language for a feed - only > for the components of it. > > Anyway, I've heard enough arguments in favour of xml:lang that I'll > accept that it is a necessary cost. > > > My other issue was that we need to state which core elements are > language sensitive and which are language neutral, otherwise > implementors will guess and language tags will get lost. We also need > to state what happens to extensions. I'd suggest that if we go with > PaceExtensionConstruct, then Simple Extension constructs are language > sensitive (although I really don't mind them being language neutral > either - I'm not convinced either way). Structured Language constructs > MAY be language sensitive (so if you don't know how to interpret them > specifically, then you MUST preserve the language tag). > > > So I am now -0.5 to PaceSimpleLanguageTagging, but I think that there > are still some issues, so I think we need another Pace that makes it > clear what xml:lang applies to. > > > BTW: > > When no xml:lang is in context, is the default language be > language neutral (ie: xml:lang=""), or is it determined by the > envelope, eg: a HTTP Content-Language header? > > > -- > Dave > -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Tue Jan 25 21:57: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 VAA11717 for ; Tue, 25 Jan 2005 21:57: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 j0Q2gvoL041470; Tue, 25 Jan 2005 18:42: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 j0Q2gvM8041469; Tue, 25 Jan 2005 18:42: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 j0Q2guuZ041456 for ; Tue, 25 Jan 2005 18:42:56 -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 1Ctcjm-0002Nw-3i; Wed, 26 Jan 2005 02:16:54 +0000 Message-ID: <41F6FD96.1010006@franklinmint.fm> Date: Tue, 25 Jan 2005 21:16:54 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Duerst CC: Walter Underwood , Atom Syntax Subject: Re: PaceMustBeWellFormed status References: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> <9E656C44A03320C76D0142CC@diva.verity.com> <41F6AE71.7060905@franklinmint.fm> <635613EB127E90365E12AD5C@diva.verity.com> <41F6B859.6080103@franklinmint.fm> <9ED7AC6C9E0C9411A5EFEF3F@diva.verity.com> <41F6C9A3.1060600@franklinmint.fm> <6.0.0.20.2.20050126090249.0776beb8@localhost> In-Reply-To: <6.0.0.20.2.20050126090249.0776beb8@localhost> 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 Martin Duerst wrote: > >> > >> Atom feeds served over HTTP MUST be well-formed XML 1.0, as defined > in Section 2.1 of the XML specification > . Furthermore, the > concept of XML well-formedness relies on first determining the > character encoding of the XML document. RFC 3023 defines how to > determine the character encoding of XML documents served over HTTP. > > > > > >The first sentence is redundant because all Atom feeds must be > well-formed. The second sentence is plainly false. The two concepts > are unrelated. > > Could you explain/substantiate your claim that the second sentence > is plainly false? I understand it to be true, and I have implementation > experience with the W3C Markup Validator to back it up. Illegal characters are fatal errors, which are quite likely when processing a document with the wrong encoding. Fatal errors aren't necessarily the result of ill-formed documents. In this case, the term "well-formed" seems to come down to the "Char" production, which is arrived at after decoding. It's possible to process an XML document with the wrong character encoding and still have a well-formed XML document. In any case, this Pace is totally wrapped up in HTTP, pedantic, and incorrect in numerous ways. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Jan 25 21:57: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 VAA11735 for ; Tue, 25 Jan 2005 21:57: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 j0Q2kZAQ042059; Tue, 25 Jan 2005 18:46: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 j0Q2kZ18042058; Tue, 25 Jan 2005 18:46:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from localhost.localdomain (air643.startdedicated.com [69.64.38.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0Q2kY3h042050 for ; Tue, 25 Jan 2005 18:46:34 -0800 (PST) (envelope-from david@blojsom.com) Received: (qmail 3762 invoked from network); 26 Jan 2005 02:29:17 -0000 Received: from alb-24-195-129-34.nycap.rr.com (HELO ?10.0.1.2?) (24.195.129.34) by air643.startdedicated.com with SMTP; 26 Jan 2005 02:29:17 -0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 25 Jan 2005 21:48:00 -0500 Subject: Re: PaceIRI status From: David Czarnecki To: atom-syntax Message-ID: In-Reply-To: <6.0.0.20.2.20050126092953.077a70f8@localhost> 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/25/05 7:45 PM, "Martin Duerst" wrote: > > At 01:52 05/01/26, Paul Hoffman wrote: >> >> At 9:16 AM +0100 1/25/05, Julian Reschke wrote: >>> I saw some concerns (with which I agree) that requiring the presence of > an IDN library is problematic. As far as I can tell, it's likely to be > ignored by developers of clients that run on somwehat constrained devices. > > Just a correction to what Julian wrote: Stringprep may be ignored > or partially ignored, because it requires lots of data, but I don't > think the Unicode->punycode conversion will be ignored. > > >> I would like to hear more from developers whether or not they think this > is a problem. (I'm asking this wearing my co-chair-looking-for-consensus > hat, not my author-of-IDN-and-stringprep hat.) > > Although I don't have any experience with developing blogging tools, > I have some experience in integrating IDN support into a browser, and > I can report on some other browsers. I hope this breaks the ice for > others to chip in. > From an SDK perspective, there are a number of libraries available to handle IDN support. As a Java person developing blogging tools, I've looked at the following. Hope this helps. Name: IDN SDK Vendor: Verisign URL: http://www.verisign.com/products-services/naming-and-directory-services/nami ng-services/internationalized-domain-names/idn-registrars/page_001408.html License: Apache/BSD Name: Java-IDNA (now part of GNU IDN Library) Vendor: GNU URL: http://www.gnu.org/software/libidn/ License: LGPL International Components for Unicode for Java (there are also C/C++ bindings which also have IDN support) Vendor: IBM URL: http://oss.software.ibm.com/icu4j/ License: IBM Open Source License ( http://oss.software.ibm.com/cvs/icu/~checkout~/icu/license.html) -David From owner-atom-syntax@mail.imc.org Tue Jan 25 22:05: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 WAA12230 for ; Tue, 25 Jan 2005 22:05: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 j0Q2vF0P042685; Tue, 25 Jan 2005 18:57: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 j0Q2vFg7042684; Tue, 25 Jan 2005 18:57:15 -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 j0Q2vE98042678 for ; Tue, 25 Jan 2005 18:57:14 -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 7F6D04EFB4; Tue, 25 Jan 2005 21:57:12 -0500 (EST) Message-Id: <6.0.0.20.2.20050126113553.071ac358@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 26 Jan 2005 11:38:57 +0900 To: Tim Bray , Atom Syntax From: Martin Duerst Subject: Re: PaceIRI status: RFC 3987 and STD 66, RFC 3986, published In-Reply-To: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.com> References: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.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 09:17 05/01/25, Tim Bray wrote: > >If there were no further discussion: It's hard to see how to avoid adopting this now that IRIs are standards-track RFC. -Tim Some good news: The IRI spec is now published as RFC 3987 (Proposed Standard, http://www.ietf.org/rfc/rfc3987.txt). The update of the URI spec, known as RFC2396bis, is now published as STD 66, RFC 3986. Even less reason for not adopting them. Editors, please update your references. I'll update PaceIRI in a day or two. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Jan 25 22: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 WAA15105 for ; Tue, 25 Jan 2005 22: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 j0Q3eAel045199; Tue, 25 Jan 2005 19:40: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 j0Q3eAZ0045198; Tue, 25 Jan 2005 19:40: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 j0Q3e9Fm045166 for ; Tue, 25 Jan 2005 19:40:10 -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, 26 Jan 2005 16:40:20 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 26 Jan 2005 14:39:37 +1100 Subject: Re: PaceMustBeWellFormed status From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <9ED7AC6C9E0C9411A5EFEF3F@diva.verity.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 26/1/05 8:58 AM, "Walter Underwood" wrote: > An external transport protocol (e.g. HTTP with text/xml content-type) > may force the document to be decoded as US-ASCII. In that case ... +1 e. From owner-atom-syntax@mail.imc.org Tue Jan 25 22:59: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 WAA15403 for ; Tue, 25 Jan 2005 22:59: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 j0Q3nYFu045829; Tue, 25 Jan 2005 19: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 j0Q3nYo8045828; Tue, 25 Jan 2005 19:49: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 j0Q3nXwV045817 for ; Tue, 25 Jan 2005 19:49:33 -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 1CteBP-0003JG-V1; Wed, 26 Jan 2005 03:49:32 +0000 Message-ID: <41F7134C.4080508@franklinmint.fm> Date: Tue, 25 Jan 2005 22:49:32 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom-Syntax Subject: Re: Issues with draft-ietf-atompub-format-04 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 26/1/05 11:03 AM, "Robert Sayre" wrote: > > > >>>It is a bit vague that this TYPE attribute differs from the one in >>>section 3.1.1. Where this one MUST have a MIME type as value the other >>>MUST NOT. >>> >>> >>This is incorrect. >> >> > >huh? > >link constructs MAY have a type attribute whose value MUST be a MIME type > >text constructs MAY have a type attribute whose value MUST be one of TEXT, >HTML, or XHTML, and MUST NOT be a MIME type. > > Ah, you're right. Still don't see how it's vague, though. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Jan 25 23:01: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 XAA15575 for ; Tue, 25 Jan 2005 23:01: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 j0Q3qrt9046050; Tue, 25 Jan 2005 19: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 j0Q3qrnC046049; Tue, 25 Jan 2005 19:52: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 j0Q3qpf9046041 for ; Tue, 25 Jan 2005 19:52: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); Wed, 26 Jan 2005 16:53:32 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 26 Jan 2005 13:37:28 +1100 Subject: Re: PaceFeedLink 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 26/1/05 4:44 AM, "Tim Bray" wrote: >> Agreed. Then the only comment that remains is: >> >> # Also, could an additional requirement be added. Namely that >> # aggregators use the URI in |rel="self"| to check for the feed next >> # time? > > -1 > > If I got the feed from location X, I may choose to do so again for > perfectly good reasons even it says "my real location is Y". Why > micromanage? -Tim I also concur. An aggregator is free to do so, but I don't think it should be a requirement. We already have a mechanism for the publisher to redirect requests to a new location (HTTP 304, 301). An aggregator might also only do so in extremis - if the feed starts going 404, it could then try the last cached /feed/head/link[@rel='self']. e. From owner-atom-syntax@mail.imc.org Tue Jan 25 23:01: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 XAA15595 for ; Tue, 25 Jan 2005 23:01: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 j0Q3qxtN046070; Tue, 25 Jan 2005 19:52: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 j0Q3qxvg046069; Tue, 25 Jan 2005 19:52: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 j0Q3qw5r046061 for ; Tue, 25 Jan 2005 19:52:59 -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, 26 Jan 2005 16:53:36 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 26 Jan 2005 14:52:45 +1100 Subject: Re: PaceFeedLink From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <6.0.0.20.2.20050126094816.077844d0@localhost> 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 26/1/05 11:50 AM, "Martin Duerst" wrote: >> A relative URI would only be useful if there is in fact an xml:base in >> effect. With no xml:base then the relative reference would be useless. > > That's pretty obvious, and applies to all other links. If we want to > point that out in the Atom spec, it should be done in the section > that talks about xml:base. What's not so obvious is that the most common situation for feed documents is that the agent knows what the source location context is, and thus has an implied xml:base to start with. Parsing a feed document from a file on a storage device, the source URI having been discarded ... that's not so obvious. e. From owner-atom-syntax@mail.imc.org Tue Jan 25 23:03: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 XAA15682 for ; Tue, 25 Jan 2005 23:02: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 j0Q3qtv6046058; Tue, 25 Jan 2005 19:52: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 j0Q3qtWh046057; Tue, 25 Jan 2005 19:52:55 -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 j0Q3qrwf046044 for ; Tue, 25 Jan 2005 19:52:54 -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, 26 Jan 2005 16:53:33 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 26 Jan 2005 14:22:28 +1100 Subject: Re: PaceEnclosuresAndPix status 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 j0Q3qswf046052 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 26/1/05 3:59 AM, "Asbjørn Ulsberg" wrote: >> -0.7. Turns into a kitchen sink by using it to point to things >> that are intended to be pre-fetched and presented along with the content > > I agree. I think we should have chosen another element name. turns > out to be HTML's where just «everything goes». I don't like it, > but if it has to be or nothing, I'd go with . I'm also -1 on this. It muddles the semantic of the element. e. From owner-atom-syntax@mail.imc.org Tue Jan 25 23:20: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 XAA16814 for ; Tue, 25 Jan 2005 23:20: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 j0Q41UKR047088; Tue, 25 Jan 2005 20:01: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 j0Q41UiZ047087; Tue, 25 Jan 2005 20:01: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 j0Q41SBC047078 for ; Tue, 25 Jan 2005 20:01: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); Wed, 26 Jan 2005 17:02:09 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 26 Jan 2005 15:01:26 +1100 Subject: Re: Issues with draft-ietf-atompub-format-04 From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <41F7134C.4080508@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 26/1/05 2:49 PM, "Robert Sayre" wrote: >> [3.1.1 says TYPE is one thing] >> [3.5.2 says TYPE is the opposite] > Ah, you're right. Still don't see how it's vague, though. It's only clear what's going on when the reader juxtaposes the two sections, and realises that the concept named 'type' in section [3.1.1] is not the same concept named 'type' in section [3.5.2]. Without that juxtaposition, the reader might well never realise that 'type' != 'type' and conflate the two concepts. Even you made that mistake just now, and you're the editor of the document. Pity the poor reader. Looking at it from a usability of specifications p.o.v., it doesn't hurt to have cross references. e. From owner-atom-syntax@mail.imc.org Tue Jan 25 23:33: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 XAA17528 for ; Tue, 25 Jan 2005 23:33: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 j0Q4CDBo048239; Tue, 25 Jan 2005 20:12: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 j0Q4CCP1048234; Tue, 25 Jan 2005 20:12: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 j0Q4AiS1048102 for ; Tue, 25 Jan 2005 20:11:01 -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 1CteVp-0003YR-MQ; Wed, 26 Jan 2005 04:10:37 +0000 Message-ID: <41F7183E.50809@franklinmint.fm> Date: Tue, 25 Jan 2005 23:10:38 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: Issues with draft-ietf-atompub-format-04 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: >>Ah, you're right. Still don't see how it's vague, though. >> >> > >It's only clear what's going on when the reader juxtaposes the two sections, >and realises that the concept named 'type' in section [3.1.1] is not the >same concept named 'type' in section [3.5.2]. Without that juxtaposition, >the reader might well never realise that 'type' != 'type' and conflate the >two concepts. Even you made that mistake just now, and you're the editor of >the document. Pity the poor reader. > > I made that mistake because the draft in front of me is organized quite differently than the one in front of you. Bring this issue up again after the next draft if you still think it's worthwhile to embark on a campaign to rename an attribute. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Jan 26 00:21: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 AAA20917 for ; Wed, 26 Jan 2005 00:21: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 j0Q59Tht051394; Tue, 25 Jan 2005 21:09: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 j0Q59Tve051393; Tue, 25 Jan 2005 21:09:29 -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 j0Q59SS3051385 for ; Tue, 25 Jan 2005 21:09:28 -0800 (PST) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 26 Jan 2005 05:09:22 -0000 Received: from dsl-213-023-058-036.arcor-ip.net (EHLO helix) (213.23.58.36) by mail.gmx.net (mp013) with SMTP; 26 Jan 2005 06:09:22 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Robert Sayre Cc: atom-syntax@imc.org Subject: Re: PaceMustBeWellFormed status Date: Wed, 26 Jan 2005 06:10:06 +0100 Message-ID: <423424d3.192324343@smtp.bjoern.hoehrmann.de> References: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> <9E656C44A03320C76D0142CC@diva.verity.com> <41F6AE71.7060905@franklinmint.fm> In-Reply-To: <41F6AE71.7060905@franklinmint.fm> 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 * Robert Sayre wrote: >I'm very -1 on this, since it makes the definition of the Atom format an >HTTP message, rather than an XML document. It seems common practise to include requirements for implementations of a format into the specification of the format. Why should these be kept separate? In fact, I see a number of statements ala "Processors MUST" in the current draft. Do you mean these should be removed? -- 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 Wed Jan 26 00:24: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 AAA21114 for ; Wed, 26 Jan 2005 00:24: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 j0Q5BHYc051483; Tue, 25 Jan 2005 21:11: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 j0Q5BHZQ051482; Tue, 25 Jan 2005 21:11:17 -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 j0Q5BGYL051475 for ; Tue, 25 Jan 2005 21:11:17 -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 <0IAW00JLQRI5E040@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Wed, 26 Jan 2005 06:06:05 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IAW004TURV6HC50@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Wed, 26 Jan 2005 06:13:54 +0100 (CET) Date: Wed, 26 Jan 2005 06:11:28 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: content for text/ or +xml SHOULD be local? (was: Re: Hash for Links) In-reply-to: <6.0.0.20.2.20050111163947.07a77f10@localhost> To: Martin Duerst , Robert Sayre 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: <1f2ed5cd050105162514f7773f@mail.gmail.com> <1f2ed5cd050106050455c75c9d@mail.gmail.com> <2bcdc7c405010609374df235f3@mail.gmail.com> <41E0464A.6090802@franklinmint.fm> <41E049A8.1050903@franklinmint.fm> <6.0.0.20.2.20050111163947.07a77f10@localhost> 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 Tue, 11 Jan 2005 16:46:35 +0900, Martin Duerst wrote: >> "If the value of type begins with "text/" or ends with "+xml", the >> content SHOULD be local; that is to say, no "src" attribute should be >> provided." > > When I read this, I was somewhat surprised to find a SHOULD. > A should, in IETF terms, is really quite strong. I'd prefer > a wording such as: > > "In general, content with value of type beginning with "text/" or > ending with "+xml" will be inline; that is to say, no "src" attribute > is provided." I'm fine with both wordings, but: > In both cases, adding something like "Such content is usually > short, and in that case, carrying it inline is more efficient." > covers the rationale I know about. There may be other rationales. - I think the word 'inline' is much better than 'local'. So no matter which wording is used in the specification, the content should be 'inline', not 'local'. -- 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 Wed Jan 26 00:30: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 AAA21247 for ; Wed, 26 Jan 2005 00:30: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 j0Q5Fct3051641; Tue, 25 Jan 2005 21:15: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 j0Q5FcPD051640; Tue, 25 Jan 2005 21:15:38 -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 j0Q5FXFm051631 for ; Tue, 25 Jan 2005 21:15:33 -0800 (PST) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 26 Jan 2005 05:15:27 -0000 Received: from dsl-213-023-058-036.arcor-ip.net (EHLO helix) (213.23.58.36) by mail.gmx.net (mp024) with SMTP; 26 Jan 2005 06:15:27 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Tim Bray Cc: atom-syntax@imc.org Subject: Re: PaceMustBeWellFormed status Date: Wed, 26 Jan 2005 06:16:12 +0100 Message-ID: <423526c9.192826515@smtp.bjoern.hoehrmann.de> References: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f505012417125b1e4d7c@mail.gmail.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: >On Jan 24, 2005, at 5:12 PM, Joe Gregorio wrote: >> It's good work but it belongs in a primer or best practices document. > >+1. I like it, I'd like to use it somewhere, but I don't think it >belongs in the core spec. -Tim I am afraid, if requirements ala "clients MUST stop processing at the first well-formedness error" are not in the "core spec", implementers might miss them, in fact, I would argue that the requirement does not apply if it is not part of the conformance requirements for Atom format implementations. -- 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 Wed Jan 26 00: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 AAA21440 for ; Wed, 26 Jan 2005 00:33: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 j0Q5PPD9052025; Tue, 25 Jan 2005 21:25: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 j0Q5PPeA052024; Tue, 25 Jan 2005 21:25: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 (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j0Q5PNKW052018 for ; Tue, 25 Jan 2005 21:25:23 -0800 (PST) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 26 Jan 2005 05:25:17 -0000 Received: from dsl-213-023-058-036.arcor-ip.net (EHLO helix) (213.23.58.36) by mail.gmx.net (mp002) with SMTP; 26 Jan 2005 06:25:17 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Tim Bray Cc: Atom Syntax Subject: Re: PaceMustBeWellFormed status Date: Wed, 26 Jan 2005 06:26:02 +0100 Message-ID: <423627d3.193092484@smtp.bjoern.hoehrmann.de> References: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> In-Reply-To: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> 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: >If there were no further discussion: The WG completely failed to >converge to consensus on these issues last time around. Consensus can >still be found here. -Tim I would suggests we contact implementers and ask them whether they will conform to these requirements or not. If we are not convinced that they will implement the spec as written, I consider the requirements point- less and misleading. How do we expect to manage updates to RFC3023 with/without this Pace? -- 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 Wed Jan 26 01: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 BAA24285 for ; Wed, 26 Jan 2005 01:30: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 j0Q62X70054715; Tue, 25 Jan 2005 22: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 j0Q62XZX054714; Tue, 25 Jan 2005 22:02:33 -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 j0Q62WNO054678 for ; Tue, 25 Jan 2005 22:02:32 -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 <0IAW00J9RTVLCL90@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Wed, 26 Jan 2005 06:57:21 +0100 (CET) Received: from quark ([80.202.95.63]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IAW004BZU8MHO90@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Wed, 26 Jan 2005 07:05:10 +0100 (CET) Date: Wed, 26 Jan 2005 07:02:44 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: Revisiting feed discovery In-reply-to: To: Eric Scheid 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: 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, 21 Jan 2005 17:35:05 +1100, Eric Scheid wrote: > How is a resource which shows the last 15 entries as of today an > "alternative" representation of an entry which was published six months > ago and has long slipped out of the sliding window? It isn't, and that's not what I meant. I think 'alternate' links are being overloaded with these kinds of meanings all the time; e.g. individual HTML pages pointing to the feed in which they occur as RSS items as 'alternate'. That's wrong and I agree that we should have another type of link relation for those links. But I'm not sure 'feed' is the correct one. > Its not the best word, but others which are better are already taken for > other purposes (eg "source", "origin", etc), or are clumsy word-pairs > which are still not properly indicative of the ongoing publishing nature > (eg. DC's "part-of"). I think 'part-of' is better. It's a relation and describes accurately what the link is pointing to. In the feed one could even have 'rev' links to go the other way, although that isn't necessary. -- 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 Wed Jan 26 01: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 BAA25368 for ; Wed, 26 Jan 2005 01: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 j0Q6ZxWF067374; Tue, 25 Jan 2005 22:35: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 j0Q6ZxTZ067373; Tue, 25 Jan 2005 22:35: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 j0Q6ZwEX067353 for ; Tue, 25 Jan 2005 22:35: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); Wed, 26 Jan 2005 19:36:38 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 26 Jan 2005 17:35:56 +1100 Subject: Re: Revisiting feed discovery 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 j0Q6ZxEX067366 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 26/1/05 5:02 PM, "Asbjørn Ulsberg" wrote: >> How is a resource which shows the last 15 entries as of today an >> "alternative" representation of an entry which was published six months >> ago and has long slipped out of the sliding window? > > It isn't, and that's not what I meant. I think 'alternate' links are being > overloaded with these kinds of meanings all the time; e.g. individual HTML > pages pointing to the feed in which they occur as RSS items as > 'alternate'. That's wrong and I agree that we should have another type of > link relation for those links. But I'm not sure 'feed' is the correct one. There is a special case of html pages for which rss/atom feeds are an "alternate" -- those html pages which contain the most recently published entries, sliding window style. Sadly, while 'alternate' is appropriate for those resources it was then conflated with the semantic of "here is the xml resource you can subscribe to". >> Its not the best word, but others which are better are already taken for >> other purposes (eg "source", "origin", etc), or are clumsy word-pairs >> which are still not properly indicative of the ongoing publishing nature >> (eg. DC's "part-of"). > > I think 'part-of' is better. It's a relation and describes accurately what > the link is pointing to. In the feed one could even have 'rev' links to go > the other way, although that isn't necessary. Ah, but an Atom entry would also have a "part-of" relationship to an Atom Feed Document which is the collected entries for the month of June 2004, and that Atom Feed Document is not the one you would subscribe to for future publications of entries. This is making the same mistake as above with "alternate". e. From owner-atom-syntax@mail.imc.org Wed Jan 26 02:57: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 CAA28816 for ; Wed, 26 Jan 2005 02:57: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 j0Q7hOiN093767; Tue, 25 Jan 2005 23:43: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 j0Q7hO32093766; Tue, 25 Jan 2005 23:43: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 j0Q7hOKD093757 for ; Tue, 25 Jan 2005 23:43:24 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 3792 invoked by uid 17064); 26 Jan 2005 07:43:24 -0000 Received: from unknown (HELO [192.168.0.5]) ([83.112.133.114]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 26 Jan 2005 07:43:24 -0000 In-Reply-To: <924972221.20050126012058@djpowell.net> References: <8E003BC2-6E66-11D9-9797-000A95A51C9E@textuality.com> <924972221.20050126012058@djpowell.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: AtomAsRDF step 2 Date: Wed, 26 Jan 2005 08:43:06 +0100 To: Dan Brickley , David Powell X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thanks David. I take it that you would be +1 if you thought the AtomAsRDF project were feasible. Thanks a lot for the list of problems you think this entails. These need to be considered one by one. On 26 Jan 2005, at 02:20, David Powell wrote: > >> PaceAttributesNamespace > > I'm -1 on this. It seems to be authorising a RDF users to do a > transform on Atom Syntax in order to make it more RDF/XML-like. > > If RDF users have to transform the content in order to interpret it as > RDF/XML (which they do), then they might as well transform it to a > decent RDF model which properly models the entities and properties > involved in the feed. We don't need the format spec to authorize RDF > users to do this - they can just do it. The purpose of AtomAsRDF is not so much to allow RDFers to have an easy life (we are purposely seeking minimal changes to Atom, and maximum hoop jumping for RDFers), but to make it easy to specify a clear and powerful extension framework for Atom. If AtomAsRDF succeeds then we can simply build on the extensibility of RDF. Extensibility is part of the Atom Working group charter. > I don't think that tweaking an Atom document and interpreting it as > RDF/XML is going to produce a sensible RDF model. I need skeptics to help me test my ideas. But the benefits are too big to not at least try this out. For one it could give Atom the claim to have dealt with the RSS wars, thereby getting the following perhaps of both camps. So to your specific problems: > There are also a number of technical problems: > > * The attribute namespace prefixing problem solved by this Pace ok. done. Thanks. So it is +1 for the AttributesNamespace Pace ;-) > * atom:author defaulting won't be modelled sensibly Very simple to change. And it is something that should be altered anyway. Paul Hoffman has said so on the 4th January. Dan Brickley just suggested that we need to find a way to state that the email and perhaps uri elements be inverse functional. Currently they are defined to be functional. I will open a pace for this. The nice thing is that this is an improvement that AtomAsRDF does not absolutely need, but that would improve atom anyway. > * The xml:lang and xml:base context won't be preserved by Text > constructs and Extensions if they are modelled as RDF XML > Literals.[1] This is a more serious claim. It needs to be looked into. > > * parseType="Resource" / parseType="Literal" needs to be assumed in > certain places. That is not a difficult problem to solve. It can be placed in the DTD. And be specified easily to be a hidden element in Atom. > If we try to solve all of these problems, then we are going to have to > do a fairly complicated transformation that needs to be applied to > produce a what could end up a quirky sub-optimal model. As I mentioned above the point is to make it easy to explain how atom can be extended in a well structured manner. If RDFers have to jump through hoops that is less of a problem. It may be a problem for Atom only so far as this may suggest to Atomers that they have designed something unnecessarily complex. > I'd rather us make sure that we have designed the format spec well > enough that it has a clear model for core elements and extensions. > > Then the RDFers can come up with a clear well-designed RDF vocabulary > for Atom and a mapping from Atom format to RDF (via XSLT?). As far as the extensibility problem is concerned you would also need the following: given an RDF graph mapped to by your xslt transformed rdf, you would need to specify how this graph can be extended in some way and then mapped back to produce an clearly understandable version of extended Atom, that should easily be transformable back into your model. And I think that AtomAsRDF is a hell of a lot simpler road to travel than that. > I've just posted this as an informal proposal on the Wiki suggesting > that we let an RDF mapping should be defined outside of the format > specification, and that we should avoid making this impossible: > > http://intertwingly.net/wiki/pie/MinimalRdfProposal I am trying the optimum strategy here. I think we should pursue this as far as we can, if not all other strategies will be left as options. In any case we are both moving in the same direction. Henry Story http://bblfish.net/ > [1] > http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/#sec-Limitations > > -- > Dave > From owner-atom-syntax@mail.imc.org Wed Jan 26 03:03: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 DAA29443 for ; Wed, 26 Jan 2005 03:03: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 j0Q7t38m098086; Tue, 25 Jan 2005 23:55: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 j0Q7t38O098085; Tue, 25 Jan 2005 23:55:03 -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 j0Q7t1tQ098038 for ; Tue, 25 Jan 2005 23:55:02 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 26 Jan 2005 07:54:55 -0000 Received: from pD9FF0344.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.3.68) by mail.gmx.net (mp011) with SMTP; 26 Jan 2005 08:54:55 +0100 X-Authenticated: #1915285 Message-ID: <41F74CCB.3020307@gmx.de> Date: Wed, 26 Jan 2005 08:54:51 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Duerst CC: Bjoern Hoehrmann , atom-syntax@imc.org Subject: Re: PaceIRI status References: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F6007B.8000008@gmx.de> <6.0.0.20.2.20050125173750.041c9958@localhost> <41F649A0.7060706@gmx.de> <42194c32.136867687@smtp.bjoern.hoehrmann.de> <41F65380.7090501@gmx.de> <421d5ad6.140615437@smtp.bjoern.hoehrmann.de> <41F65D77.6060701@gmx.de> <6.0.0.20.2.20050126075033.076c5890@localhost> In-Reply-To: <6.0.0.20.2.20050126075033.076c5890@localhost> 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 Martin Duerst wrote: > ... > Bjoern was making a vaild, but fine, point: Because we decided to > refer to RFC2396bis, rather than to RFC2396, we already have bought > into the fact that RFC2396bis allows percent-encoded domain names, > and thus essentially requires IDN support. (apart from the basic > fact that no resolver is required to resolve all URIs or IRIs) > ... OK, thanks for making me aware of this subtle change. > ... Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Wed Jan 26 04:55: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 EAA06212 for ; Wed, 26 Jan 2005 04:55: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 j0Q9ilZG034721; Wed, 26 Jan 2005 01:44: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 j0Q9ildv034720; Wed, 26 Jan 2005 01:44:47 -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 j0Q9ileZ034711 for ; Wed, 26 Jan 2005 01:44:47 -0800 (PST) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id EE5214EF94; Wed, 26 Jan 2005 04:44:46 -0500 (EST) Date: Wed, 26 Jan 2005 04:44:46 -0500 From: Dan Brickley To: Atom Syntax Subject: Re: PaceEnclosuresAndPix status Message-ID: <20050126094446.GA30454@homer.w3.org> References: <92798DAC-6E66-11D9-9797-000A95A51C9E@textuality.com> <0B614799-4533-42FD-A790-51C005A85C08@sdf1.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0B614799-4533-42FD-A790-51C005A85C08@sdf1.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: * Ray Slakinski [2005-01-25 10:40-0500] > > +1 from me, I'm happy to see this added! +1 likewise to http://www.intertwingly.net/wiki/pie/PaceEnclosuresAndPix Dan > On 24-Jan-05, at 7:18 PM, Tim Bray wrote: > >If there were no further discussion: Got no -1's, seems useful, needed > >for feature parity with RSS2, will likely go in absent some > >objections. -Tim From owner-atom-syntax@mail.imc.org Wed Jan 26 05:45: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 FAA09360 for ; Wed, 26 Jan 2005 05:45: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 j0QAWdKj049573; Wed, 26 Jan 2005 02:32: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 j0QAWdFI049572; Wed, 26 Jan 2005 02:32: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.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0QAWYea049496 for ; Wed, 26 Jan 2005 02:32:35 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so121247rnz for ; Wed, 26 Jan 2005 02:32: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=WvJ2k7UjP4BZYDoQgBPksPistnVYOoLYN3bKF2ut4omsMC/lP9wNvdByTXHZEmGFGSq1/qGDqgm/Ag6BbQ91dJHpH1jFoYtXuzUScRRQoNcuKeqoLgiNdt4uFlyHOYmuGB2Db22sCA/3huGtxPAxcLbFLMQ0RLvP73ehICzXe1k= Received: by 10.38.179.2 with SMTP id b2mr358955rnf; Wed, 26 Jan 2005 02:32:27 -0800 (PST) Received: by 10.38.179.71 with HTTP; Wed, 26 Jan 2005 02:32:26 -0800 (PST) Message-ID: <1f2ed5cd0501260232167d7012@mail.gmail.com> Date: Wed, 26 Jan 2005 11:32:26 +0100 From: Danny Ayers Reply-To: Danny Ayers To: David Powell Subject: Re: PaceAttributesNamespace status Cc: Tim Bray , Atom Syntax In-Reply-To: <924972221.20050126012058@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <8E003BC2-6E66-11D9-9797-000A95A51C9E@textuality.com> <924972221.20050126012058@djpowell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 26 Jan 2005 01:20:58 +0000, David Powell wrote: > > > > PaceAttributesNamespace > > I'm -1 on this. It seems to be authorising a RDF users to do a > transform on Atom Syntax in order to make it more RDF/XML-like. That's really orthogonal from the intention. > If RDF users have to transform the content in order to interpret it as > RDF/XML (which they do), then they might as well transform it to a > decent RDF model which properly models the entities and properties > involved in the feed. We don't need the format spec to authorize RDF > users to do this - they can just do it. True. But that "decent RDF model" will presumably be based on the model implicit in the Atom spec. But there are points which can't be carried from the spec as it stands into the world of resources at large - the unqualified attributes. > I don't think that tweaking an Atom document and interpreting it as > RDF/XML is going to produce a sensible RDF model. That isn't really the intention, although there's no reason to make the transformation any more complicated than it needs to be. > There are also a number of technical problems: > > * The attribute namespace prefixing problem solved by this Pace > > * atom:author defaulting won't be modelled sensibly > > * The xml:lang and xml:base context won't be preserved by Text > constructs and Extensions if they are modelled as RDF XML Literals.[1] > > * parseType="Resource" / parseType="Literal" needs to be assumed in > certain places. Only the first is covered by this Pace. > If we try to solve all of these problems, then we are going to have to > do a fairly complicated transformation that needs to be applied to > produce a what could end up a quirky sub-optimal model. This is extrapolating a lot way from the proposal. > I'd rather us make sure that we have designed the format spec well > enough that it has a clear model for core elements and extensions. Yes, exactly. > Then the RDFers can come up with a clear well-designed RDF vocabulary > for Atom and a mapping from Atom format to RDF (via XSLT?). There is a clear mapping of construct *names* from Atom to the RDF world (the element names have URIs), but the unprefixed attributes don't have URIs. > I've just posted this as an informal proposal on the Wiki suggesting > that we let an RDF mapping should be defined outside of the format > specification, and that we should avoid making this impossible: > > http://intertwingly.net/wiki/pie/MinimalRdfProposal "Interpreting Atom syntax as RDF/XML is not possible without applying transformations. " I don't care about Atom syntax as RDF/XML per se, what I'm interested in is Atom as RDF. " Atom should define a consistent model for its core elements." Exactly. What it currently lacks is unambiguous names for the attributes outside of document instances. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Jan 26 06:01: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 GAA10406 for ; Wed, 26 Jan 2005 06:01: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 j0QAlqdk054470; Wed, 26 Jan 2005 02:47: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 j0QAlq4F054469; Wed, 26 Jan 2005 02:47:52 -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 j0QAlpbP054435 for ; Wed, 26 Jan 2005 02:47:51 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so121867rnz for ; Wed, 26 Jan 2005 02:47: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:mime-version:content-type:content-transfer-encoding; b=BtNRdDTGUeGU9XTqnwmnVFBJ6IAQ2KV+WbsdE3TPteOvn3AANmPtWkSRc+udDMjKNzQpaQncByjNEzsZywYu2+JtIFVpWJ60MgM91ecyU5Z4GSZp+NvdUViBGVtAh2s+bWb7KJ9j6CBSid6ypPFYHbsgE3oE00JPFqLqVz0Jkik= Received: by 10.38.206.29 with SMTP id d29mr181062rng; Wed, 26 Jan 2005 02:47:45 -0800 (PST) Received: by 10.38.179.71 with HTTP; Wed, 26 Jan 2005 02:47:45 -0800 (PST) Message-ID: <1f2ed5cd05012602474fc907a1@mail.gmail.com> Date: Wed, 26 Jan 2005 11:47:45 +0100 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: PaceAttributesNamespace is *not* about syntax! 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 added the following note to the Pace: A lot of the critical response to this Pace has been based on the assumption that it is about changes to the Atom syntax. Nothing could be farther from the truth. Within Atom format it will remain mandatory that documents are produced with no-namespace attributes. This Pace is about the model. Resources on the Web are generally given URIs. With RDF, it has been found useful to also assign URIs to relations, so they too are uniformly are uniquely defined. As it stands, most of the constructs and relations within Atom already have URIs - the element names are namespace-qualified. This isn't the case for the attributes. By saying that the no-namespace attributes can be interpreted as having names in the Atom namespace gives them URIs. As well as simplifying the RDF model the approach described in this Pace should also be useful for reusing Atom attributes in extensions. http://intertwingly.net/wiki/pie/PaceAttributesNamespace Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Jan 26 08:35: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 IAA23625 for ; Wed, 26 Jan 2005 08:35: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 j0QDBcrU004966; Wed, 26 Jan 2005 05:11: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 j0QDBcWV004964; Wed, 26 Jan 2005 05:11:38 -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 j0QDBbVW004954 for ; Wed, 26 Jan 2005 05:11:38 -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 04AD44EFB4; Wed, 26 Jan 2005 08:11:35 -0500 (EST) Message-Id: <6.0.0.20.2.20050126220821.070568a8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 26 Jan 2005 22:11:17 +0900 To: Eric Scheid , Atom Syntax From: Martin Duerst Subject: Re: Issues with draft-ietf-atompub-format-04 In-Reply-To: References: <41F7134C.4080508@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 At 13:01 05/01/26, Eric Scheid wrote: >It's only clear what's going on when the reader juxtaposes the two sections, >and realises that the concept named 'type' in section [3.1.1] is not the >same concept named 'type' in section [3.5.2]. Without that juxtaposition, >the reader might well never realise that 'type' != 'type' and conflate the >two concepts. Even you made that mistake just now, and you're the editor of >the document. Pity the poor reader. > >Looking at it from a usability of specifications p.o.v., it doesn't hurt to >have cross references. I agree this is a problem. Either we find new names for the attributes so that each element has a different attribute, or we put pointers to the other 'type' attribute(s) in each section about a type attribute (and ideally also a table somewhere that shows all of them). If we don't do it, confusion will be guaranteed, and we will know we are the ones to blame. Regards, Martin. From owner-atom-syntax@mail.imc.org Wed Jan 26 09:34: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 JAA29139 for ; Wed, 26 Jan 2005 09:34: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 j0QE6JFJ010962; Wed, 26 Jan 2005 06: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 j0QE6JA4010961; Wed, 26 Jan 2005 06:06:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [69.20.61.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0QE6IJ8010952 for ; Wed, 26 Jan 2005 06:06:18 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [68.24.2.152] (000-000-665.area6.spcsdns.net [68.24.2.152]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.10) with ESMTP id j0QE37Mo005288; Wed, 26 Jan 2005 09:03:35 -0500 Message-ID: <41F7A320.9020906@intertwingly.net> Date: Wed, 26 Jan 2005 09:03: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: Danny Ayers CC: atom-syntax@imc.org Subject: Re: PaceAttributesNamespace is *not* about syntax! References: <1f2ed5cd05012602474fc907a1@mail.gmail.com> In-Reply-To: <1f2ed5cd05012602474fc907a1@mail.gmail.com> 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 Danny Ayers wrote: > I've added the following note to the Pace: > > A lot of the critical response to this Pace has been based on the > assumption that it is about changes to the Atom syntax. Nothing could > be farther from the truth. Within Atom format it will remain mandatory > that documents are produced with no-namespace attributes. This Pace is > about the model. > > Resources on the Web are generally given URIs. With RDF, it has been > found useful to also assign URIs to relations, so they too are > uniformly are uniquely defined. As it stands, most of the constructs > and relations within Atom already have URIs - the element names are > namespace-qualified. This isn't the case for the attributes. By saying > that the no-namespace attributes can be interpreted as having names in > the Atom namespace gives them URIs. > > As well as simplifying the RDF model the approach described in this > Pace should also be useful for reusing Atom attributes in extensions. > > http://intertwingly.net/wiki/pie/PaceAttributesNamespace Let's assume that there will be a non-normative appendix which describes the mapping of the Atom/XML syntax to RDF triples (possibly via a mapping to RDF/XML or possibly directly). Clearly, such an appendix would need to define a number of relations, and such relations are likely to make use of the Atom namespace. A simple introductory and declarative statement in that appendix that describes how such a mapping is done (attribute name + atom namespace) would most definately be in order. But, now lets examine the statement proposed in PaceAttributeNamespace. It essentially alerts producers of something that that they need to be aware of. Now a quesion: what do they need do different with the knowledge that the RDF mapping does this? I would assert the answer to this question is nothing. Meaning that this particular statement is not needed. Again, no issue with the mapping. No issue with describing the mapping alongside with the actual mapping. - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Jan 26 10:18: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 KAA05140 for ; Wed, 26 Jan 2005 10: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 j0QF5uPR017089; Wed, 26 Jan 2005 07: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 j0QF5uSQ017088; Wed, 26 Jan 2005 07:05:56 -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 j0QF5tTJ017073 for ; Wed, 26 Jan 2005 07:05:55 -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 <2005012615054601100cdkb5e>; Wed, 26 Jan 2005 15:05:46 +0000 Date: Wed, 26 Jan 2005 08:05:46 -0700 Subject: Re: PaceAttributesNamespace is *not* about syntax! 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: <41F7A320.9020906@intertwingly.net> 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 Wednesday, January 26, 2005, at 07:03 AM, Sam Ruby wrote: > Let's assume that there will be a non-normative appendix which > describes the mapping of the Atom/XML syntax to RDF triples (possibly > via a mapping to RDF/XML or possibly directly). Clearly, such an > appendix would need to define a number of relations, and such > relations are likely to make use of the Atom namespace. > > A simple introductory and declarative statement in that appendix that > describes how such a mapping is done (attribute name + atom namespace) > would most definately be in order. > Agreed. This issue should be addressed in an appendix rather than in the main body of the spec. From owner-atom-syntax@mail.imc.org Wed Jan 26 10: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 KAA08282 for ; Wed, 26 Jan 2005 10:41: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 j0QFTvNu018924; Wed, 26 Jan 2005 07:29: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 j0QFTvPq018923; Wed, 26 Jan 2005 07:29:57 -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 ([161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0QFTtbt018877 for ; Wed, 26 Jan 2005 07:29:55 -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 j0QFRlM2026645; Wed, 26 Jan 2005 15:27:53 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-12--402949118; protocol="application/pkcs7-signature" Message-Id: Cc: Atom Syntax From: Graham Subject: Re: PaceFeedLink Date: Wed, 26 Jan 2005 15:27:49 +0000 To: Eric Scheid X-Mailer: Apple Mail (2.619) 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--402949118 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 26 Jan 2005, at 2:37 am, Eric Scheid wrote: > I also concur. An aggregator is free to do so, but I don't think it > should > be a requirement. We already have a mechanism for the publisher to > redirect > requests to a new location (HTTP 304, 301). > > An aggregator might also only do so in extremis - if the feed starts > going > 404, it could then try the last cached /feed/head/link[@rel='self']. Very, very good point. The text needs something along the lines of "Atom producers MUST NOT expect consumers which found the document at a different URI to switch to requesting it from the URI specified.", or something less clunky. Otherwise it's going to cause all sorts of problems and arguments. Graham --Apple-Mail-12--402949118 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 9w0BCQUxDxcNMDUwMTI2MTUyNzQ5WjAjBgkqhkiG9w0BCQQxFgQUV8hfRPENbQOFjhJFkbML0Qnk I5kweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAXgqRYAsVH/EkLp2JZJV4K22B Eqmt0lw3M3kiKvj1U4fO3gstPIEID3FbaJv3Ok0pGQ/RDPNp7asdI7QjgKK9fdo9NTwRQY/zQ55L 5pq7/k2a4ppxzJAkBdDGq2bMjae++3QumuavcTYC3msLzyj7q+s5TqJ5Zh+DA29DW89UjSIIZlRe rcv/qAT4sugrwtbj7bn5ePLvE2NpMzVl5A8g4Sya3YLd2Tw2F+t4UKloieobHH2agfg/5FMO26HA CkbqlYNrx513V/wIPcVK3BchPbisDouNcjUHv/64fJ6UCP/yBcQ0l9eatYNo7gVSedhOo596gRmX /GWFOQxzIpSsugAAAAAAAA== --Apple-Mail-12--402949118-- From owner-atom-syntax@mail.imc.org Wed Jan 26 11:04: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 LAA10185 for ; Wed, 26 Jan 2005 11:04: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 j0QFrg4V021265; Wed, 26 Jan 2005 07:53: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 j0QFrghF021264; Wed, 26 Jan 2005 07:53:42 -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 j0QFreuC021258 for ; Wed, 26 Jan 2005 07:53: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 j0QFreVu010566 for ; Wed, 26 Jan 2005 08:53:40 -0700 (MST) Received: from xpa-fe1 (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 <0IAX008H3LHG80@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 26 Jan 2005 08:53:40 -0700 (MST) Received: from [192.168.1.15] ([216.113.201.159]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAX00BYKLHF9G@mail.sun.net> for atom-syntax@imc.org; Wed, 26 Jan 2005 08:53:39 -0700 (MST) Date: Wed, 26 Jan 2005 07:53:33 -0800 From: Tim Bray Subject: Re: PaceFeedLink In-reply-to: To: Graham Cc: Atom Syntax , Eric Scheid Message-id: <6E96BAD8-6FB2-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: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 26, 2005, at 7:27 AM, Graham wrote: > Very, very good point. The text needs something along the lines of > "Atom producers MUST NOT expect consumers which found the document at > a different URI to switch to requesting it from the URI specified.", > or something less clunky. Otherwise it's going to cause all sorts of > problems and arguments. +1. I can already hear the whiny emails in my head. It may be enough just to say "Software which discovers that the FeedLink URI is different from that used to retrieve the atom:feed document containing MAY choose to use the FeedLink URI for subsequent fetches." -Tim From owner-atom-syntax@mail.imc.org Wed Jan 26 11:06: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 LAA10514 for ; Wed, 26 Jan 2005 11:06: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 j0QFve2t021534; Wed, 26 Jan 2005 07:57: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 j0QFvefH021533; Wed, 26 Jan 2005 07:57:40 -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 j0QFvdH1021515 for ; Wed, 26 Jan 2005 07:57:40 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so142576rnz for ; Wed, 26 Jan 2005 07:57:34 -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=h7SUcELkoHIydNvPdML5r2qfYOB8pSD+LPr7oqB/VYd4UhOYEJm6CFlLvdqOztoMAY8xdgfe6NFZEZy6rNYrGiEhl+PUqewSSmpjZJDYDbghTvVK8FzxkqfTo/h0iZWoB9iFcahuKnffBfvTung6gxtVG5MCLevli1o1UtpVLmY= Received: by 10.38.206.28 with SMTP id d28mr50151rng; Wed, 26 Jan 2005 07:57:34 -0800 (PST) Received: by 10.38.179.71 with HTTP; Wed, 26 Jan 2005 07:57:34 -0800 (PST) Message-ID: <1f2ed5cd05012607572df5d172@mail.gmail.com> Date: Wed, 26 Jan 2005 16:57:34 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Sam Ruby Subject: Re: PaceAttributesNamespace is *not* about syntax! Cc: atom-syntax@imc.org In-Reply-To: <41F7A320.9020906@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd05012602474fc907a1@mail.gmail.com> <41F7A320.9020906@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 26 Jan 2005 09:03:12 -0500, Sam Ruby wrote: > Danny Ayers wrote: > > I've added the following note to the Pace: > > > > A lot of the critical response to this Pace has been based on the > > assumption that it is about changes to the Atom syntax. Nothing could > > be farther from the truth. Within Atom format it will remain mandatory > > that documents are produced with no-namespace attributes. This Pace is > > about the model. > > > > Resources on the Web are generally given URIs. With RDF, it has been > > found useful to also assign URIs to relations, so they too are > > uniformly are uniquely defined. As it stands, most of the constructs > > and relations within Atom already have URIs - the element names are > > namespace-qualified. This isn't the case for the attributes. By saying > > that the no-namespace attributes can be interpreted as having names in > > the Atom namespace gives them URIs. > > > > As well as simplifying the RDF model the approach described in this > > Pace should also be useful for reusing Atom attributes in extensions. > > > > http://intertwingly.net/wiki/pie/PaceAttributesNamespace > > Let's assume that there will be a non-normative appendix which describes > the mapping of the Atom/XML syntax to RDF triples (possibly via a > mapping to RDF/XML or possibly directly). Clearly, such an appendix > would need to define a number of relations, and such relations are > likely to make use of the Atom namespace. > > A simple introductory and declarative statement in that appendix that > describes how such a mapping is done (attribute name + atom namespace) > would most definately be in order. > > But, now lets examine the statement proposed in PaceAttributeNamespace. > It essentially alerts producers of something that that they need to be > aware of. Now a quesion: what do they need do different with the > knowledge that the RDF mapping does this? > > I would assert the answer to this question is nothing. Meaning that > this particular statement is not needed. Again, no issue with the > mapping. No issue with describing the mapping alongside with the actual > mapping. Although this Pace has been prompted by a desire to help ensure RDF developers are reading from the same page, it isn't actually tied to RDF at all. It's about clearly defining terms to assist interop in general. I personally think it makes good sense to define terms that appear in the Atom namespace normatively within the Atom specification. The argument given above has no effect on that - any part of the specification could be shifted to 'informative' and the answer to the question "what do they do different?" would still be "nothing". It will still be possible to treat Atom as RDF through GRDDL or whatever, whether the mapping appears normatively in the spec, in an informative appendix or on the back of an envelope somewhere in Korea. It will still be possible to add data from other namespaces whether or not they make sense. It will still be possible to read Atom with regular expressions. It will still be possible to produce ill-formed XML and label it Atom. But there are a lot of places the line could be drawn about what is normative, right now it's not very far from an RSS 2.1. Which is a little disappointing given all the time and effort the WG has spent on it. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Jan 26 11:48: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 LAA14910 for ; Wed, 26 Jan 2005 11:48: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 j0QGTDYu024056; Wed, 26 Jan 2005 08:29: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 j0QGTDb6024055; Wed, 26 Jan 2005 08:29:13 -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 j0QGTC1Y024048 for ; Wed, 26 Jan 2005 08:29:12 -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 j0QGT8qn003489; Wed, 26 Jan 2005 11:29:08 -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 CLC58098 (AUTH bob@wyman.us); Wed, 26 Jan 2005 11:29:06 -0500 (EST) Message-Id: <200501261629.CLC58098@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Graham'" , "'Eric Scheid'" Cc: "'Atom Syntax'" Subject: RE: PaceFeedLink Date: Wed, 26 Jan 2005 11:29:03 -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: AcUDv24OxUibtfyYSUu6+oIrTeJZBQAA+H5A Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > The text needs something along the lines of "Atom producers MUST > NOT expect consumers which found the document at a different > URI to switch to requesting it from the URI specified.", or > something less clunky. Otherwise it's going to cause all sorts > of problems and arguments. +1. I agree. We've found that we must take site's or file's statements about their location or the location of related resources with a "grain of salt."... Often, data found in things like autodiscovery resources provides nothing more than a hint of where something might be or where it might have been a few weeks or months ago... If people want "re-direct" they should use the formally defined redirection mechanisms. bob wyman From owner-atom-syntax@mail.imc.org Wed Jan 26 11:48: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 LAA14931 for ; Wed, 26 Jan 2005 11:48: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 j0QGck4L024693; Wed, 26 Jan 2005 08:38: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 j0QGckTX024692; Wed, 26 Jan 2005 08:38:46 -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 j0QGcjfN024661 for ; Wed, 26 Jan 2005 08:38:45 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 59895 invoked by uid 17064); 26 Jan 2005 16:38:35 -0000 Received: from unknown (HELO [192.168.0.5]) ([83.112.233.61]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 26 Jan 2005 16:38:35 -0000 In-Reply-To: <41F7A320.9020906@intertwingly.net> References: <1f2ed5cd05012602474fc907a1@mail.gmail.com> <41F7A320.9020906@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8631b39ab59dd87f9ad947318c513654@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Danny Ayers , atom-syntax@imc.org From: Henry Story Subject: Re: PaceAttributesNamespace is *not* about syntax! Date: Wed, 26 Jan 2005 17:37:58 +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 26 Jan 2005, at 15:03, Sam Ruby wrote: > [...] > But, now lets examine the statement proposed in > PaceAttributeNamespace. It essentially alerts producers of something > that that they need to be aware of. Now a quesion: what do they need > do different with the knowledge that the RDF mapping does this? > > I would assert the answer to this question is nothing. Meaning that > this particular statement is not needed. Again, no issue with the > mapping. No issue with describing the mapping alongside with the > actual mapping. I think your assertion is wrong. If they are consuming or producing extended Atom [1] they will know exactly what these extensions are referring to. It won't affect in the least consumers of simple, non extended Atom, but it will greatly help consumers and producers of extended atom. Now if you don't care about making their lives easier, then you have nothing to worry about in this pace. If you do, like I and many others, then this will be very helpful. > - Sam Ruby [1] Should we call these molecules? From owner-atom-syntax@mail.imc.org Wed Jan 26 12:12: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 MAA17132 for ; Wed, 26 Jan 2005 12:12: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 j0QH3RPo026610; Wed, 26 Jan 2005 09:03: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 j0QH3R73026609; Wed, 26 Jan 2005 09:03: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 ([161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0QH3Q9I026559 for ; Wed, 26 Jan 2005 09:03:26 -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 j0QH1jw4018404; Wed, 26 Jan 2005 17:01:45 GMT In-Reply-To: <8631b39ab59dd87f9ad947318c513654@bblfish.net> References: <1f2ed5cd05012602474fc907a1@mail.gmail.com> <41F7A320.9020906@intertwingly.net> <8631b39ab59dd87f9ad947318c513654@bblfish.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-13--397314219; protocol="application/pkcs7-signature" Message-Id: Cc: Danny Ayers , atom-syntax@imc.org, Sam Ruby From: Graham Subject: Re: PaceAttributesNamespace is *not* about syntax! Date: Wed, 26 Jan 2005 17:01:43 +0000 To: Henry Story X-Mailer: Apple Mail (2.619) 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--397314219 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 26 Jan 2005, at 4:37 pm, Henry Story wrote: > I think your assertion is wrong. If they are consuming or producing > extended Atom [1] > they will know exactly what these extensions are referring to. It won't > affect in the least consumers of simple, non extended Atom, but it > will greatly > help consumers and producers of extended atom. What will? To what does "these extensions" refer? How will "it" help who? You seem to have given up trying to get your ideas across to other people. (+1 on Sam's argument, btw) Graham --Apple-Mail-13--397314219 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 9w0BCQUxDxcNMDUwMTI2MTcwMTQ0WjAjBgkqhkiG9w0BCQQxFgQUOQu+vVVJ8F+8JzzAs89neiaF 09MweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAKZmTVQ65QjY6sdn81UO8QGmg DYFNJxij8ICDjM6PRWxi9ombQTj9Wxbt/jfN19M02+n2ePxJw6/SX2CfRDqND2Mbc2NLoEkjmqLa 84GV7Tp0DsyVODnAKXiekfXaDeDQ/PZKf+52VfHumXOCBFvBx1kTyQ7Zo0Lo9GDRrRY0Z1ZA9O+D bu/Yl3FnwBkTVAciU+V4/ypIakN11o3hCEClpa9337aXBPe+ummJkRzeff3VmQoR/VxHjlJWEuav LVBYtPIJrvI5xEd2Td/gLYn/h6nvNiIO0cx+BQQ32eMsO2CXuYbpVgT1sbNeUFSRM8f/id9DMmCo bhMADysBJpuePAAAAAAAAA== --Apple-Mail-13--397314219-- From owner-atom-syntax@mail.imc.org Wed Jan 26 12: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 MAA18365 for ; Wed, 26 Jan 2005 12:25: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 j0QHC1Ug027438; Wed, 26 Jan 2005 09: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 j0QHC1bR027437; Wed, 26 Jan 2005 09:12: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 j0QHC1ZT027426 for ; Wed, 26 Jan 2005 09:12:01 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 11750 invoked by uid 17064); 26 Jan 2005 17:12:01 -0000 Received: from unknown (HELO [192.168.0.5]) ([83.112.233.61]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 26 Jan 2005 17:12:01 -0000 In-Reply-To: References: <1f2ed5cd05012602474fc907a1@mail.gmail.com> <41F7A320.9020906@intertwingly.net> <8631b39ab59dd87f9ad947318c513654@bblfish.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3a0a09cffb909f5b93a3f6762f27f9e8@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: Re: PaceAttributesNamespace is *not* about syntax! Date: Wed, 26 Jan 2005 18:11:56 +0100 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 Robot [1], when real people come and ask me something I'll talk to them. Henry On 26 Jan 2005, at 18:01, Graham wrote: > On 26 Jan 2005, at 4:37 pm, Henry Story wrote: > >> I think your assertion is wrong. If they are consuming or producing >> extended Atom [1] >> they will know exactly what these extensions are referring to. It >> won't >> affect in the least consumers of simple, non extended Atom, but it >> will greatly >> help consumers and producers of extended atom. > > What will? To what does "these extensions" refer? How will "it" help > who? You seem to have given up trying to get your ideas across to > other people. > > (+1 on Sam's argument, btw) > > Graham [1] http://www.imc.org/atom-syntax/mail-archive/msg11659.html From owner-atom-syntax@mail.imc.org Wed Jan 26 12:40: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 MAA19797 for ; Wed, 26 Jan 2005 12:40: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 j0QHSiMn029016; Wed, 26 Jan 2005 09: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 j0QHSiK8029015; Wed, 26 Jan 2005 09:28: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 j0QHShQu028982 for ; Wed, 26 Jan 2005 09:28:44 -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 j0QHS95O001024; Wed, 26 Jan 2005 17:28:14 GMT In-Reply-To: <3a0a09cffb909f5b93a3f6762f27f9e8@bblfish.net> References: <1f2ed5cd05012602474fc907a1@mail.gmail.com> <41F7A320.9020906@intertwingly.net> <8631b39ab59dd87f9ad947318c513654@bblfish.net> <3a0a09cffb909f5b93a3f6762f27f9e8@bblfish.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-14--395728169; protocol="application/pkcs7-signature" Message-Id: Cc: Atom Syntax From: Graham Subject: Re: PaceAttributesNamespace is *not* about syntax! Date: Wed, 26 Jan 2005 17:28:10 +0000 To: Henry Story X-Mailer: Apple Mail (2.619) 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-14--395728169 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Go fuck yourself Henry, you horrible hateful humorless person. Graham On 26 Jan 2005, at 5:11 pm, Henry Story wrote: > > Graham the Robot [1], when real people come and ask me something I'll > talk to them. > > Henry > > On 26 Jan 2005, at 18:01, Graham wrote: >> On 26 Jan 2005, at 4:37 pm, Henry Story wrote: >> >>> I think your assertion is wrong. If they are consuming or producing >>> extended Atom [1] >>> they will know exactly what these extensions are referring to. It >>> won't >>> affect in the least consumers of simple, non extended Atom, but it >>> will greatly >>> help consumers and producers of extended atom. >> >> What will? To what does "these extensions" refer? How will "it" help >> who? You seem to have given up trying to get your ideas across to >> other people. >> >> (+1 on Sam's argument, btw) >> >> Graham > > [1] http://www.imc.org/atom-syntax/mail-archive/msg11659.html > --Apple-Mail-14--395728169 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 9w0BCQUxDxcNMDUwMTI2MTcyODEwWjAjBgkqhkiG9w0BCQQxFgQUqSx8BwABeeSlU8bM2oFPIu/+ ZjIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAE7DloQ96xEXN8c4wpmlEw4co suFUJlhlyDDAz21UatXrUqJJ3+ewuEXoZXVlo3BxkeCPum3VeMiPzwj8VF3V5yUKlRd8SvGZN9O4 zxzRhLcKY4QMlRloSkNR71bim9MbEd7kTe6ruvP8AIbvIR9ORt/CXgzysR8aVGrKagS9y0lcUnkB NuVtZbh/dwBGmgStoDNMSTeUoXTR3bt217tQzG0iB2u1tFtHmWkA+jdvaC3/HNeeOiD8JRCAHCek 5dmoBtTaCdH1Xsss5ebMh5DztHG8dBQVWcnMc5WG6pi3zkTKY8JFwZHgbh0fCSTaQTLim2DMCnlP cDU/dWSYxPue+gAAAAAAAA== --Apple-Mail-14--395728169-- From owner-atom-syntax@mail.imc.org Wed Jan 26 14:29: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 OAA02847 for ; Wed, 26 Jan 2005 14:29: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 j0QJGKhA038402; Wed, 26 Jan 2005 11:16: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 j0QJGKeh038401; Wed, 26 Jan 2005 11:16:20 -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 j0QJGJ6i038390 for ; Wed, 26 Jan 2005 11:16:20 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so161477rnz for ; Wed, 26 Jan 2005 11:16: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=omdYHBTttysmgSKyGq+63LruaOwq9Bt/B0W6oHFt+KsJheBebQw//NLc3MN+wiFMauOk/3CdC6ACF6/YJpQP2uSQN1wOAMpEmXtfPqBHP2MoDW9sTeTCbzPMZyRQ91jsu+GcANnvWNWbLGhKdd4qdvYgxKDnDtC++1IO0lF9Vfg= Received: by 10.38.26.40 with SMTP id 40mr129809rnz; Wed, 26 Jan 2005 11:16:12 -0800 (PST) Received: by 10.38.179.71 with HTTP; Wed, 26 Jan 2005 11:16:12 -0800 (PST) Message-ID: <1f2ed5cd05012611163deb9672@mail.gmail.com> Date: Wed, 26 Jan 2005 20:16:12 +0100 From: Danny Ayers Reply-To: Danny Ayers To: David Powell Subject: Re: PaceExtensionConstruct status Cc: atom-syntax@imc.org, henry.story@bblfish.net, danbri@w3.org In-Reply-To: <1742148530.20050125021028@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <893856C5-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f50501241659610acb49@mail.gmail.com> <1742148530.20050125021028@djpowell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 25 Jan 2005 02:10:28 +0000, David Powell wrote: +1 (allowing room for tweaks) > I'll try to post my suggested RDF road-map tomorrow - basically, I'd > like to see: > > * an Atom syntax - RDF mapping defined in a separate I-D. > > * no changes to the Atom syntax for the sake of RDF. > > * a model that maps properly onto the core Atom concepts without > getting tangled up in the Atom syntax. Yep. Expect +1s from me for anything along these lines. An appendix covering RDF compatibility mapping has been suggested. I would expect that to be brief (and wouldn't object to it being solely informative), with the bulk of the material appearing in the separate ID. But right now I'd say the challenge is to get the third item above sorted. I believe Henry's got most of an RDF/OWL model worked out - perhaps he could be persuaded to post it to the Wiki for nitpicking..? Correct me if I'm wrong - the tricky bit relating to content datatypes still needs figuring out, along with a couple of inconsistencies/weird structures within Atom. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Jan 26 14:45: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 OAA05294 for ; Wed, 26 Jan 2005 14:45: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 j0QJWLG3039606; Wed, 26 Jan 2005 11:32: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 j0QJWL7B039605; Wed, 26 Jan 2005 11:32: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.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0QJWK5G039595 for ; Wed, 26 Jan 2005 11:32:20 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so162947rnz for ; Wed, 26 Jan 2005 11:32: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:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=KOjrJSMdEmk1D9CLQdMg9ToEriOhCJghCyQ8qjRBgQbHGJZoup2jQksb28Qdxod5hYS2MmUzbRBcdu++Oo29yhZ90B9F5l9Ewur/ZnOWjOm0g1qfgmDg3g7GgGL2dtYN3XamtXZXgQE78USQn1AGcwaK0JfK/Gf8p2JXKLxjoj4= Received: by 10.38.206.28 with SMTP id d28mr146868rng; Wed, 26 Jan 2005 11:32:15 -0800 (PST) Received: by 10.38.179.71 with HTTP; Wed, 26 Jan 2005 11:32:15 -0800 (PST) Message-ID: <1f2ed5cd0501261132454ee0d@mail.gmail.com> Date: Wed, 26 Jan 2005 20:32:15 +0100 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: Re: PaceEnclosuresAndPix status In-Reply-To: <20050126094446.GA30454@homer.w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <92798DAC-6E66-11D9-9797-000A95A51C9E@textuality.com> <0B614799-4533-42FD-A790-51C005A85C08@sdf1.net> <20050126094446.GA30454@homer.w3.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1. (with proposed tweaks) On Wed, 26 Jan 2005 04:44:46 -0500, Dan Brickley wrote: > > * Ray Slakinski [2005-01-25 10:40-0500] > > > > +1 from me, I'm happy to see this added! > > +1 likewise to http://www.intertwingly.net/wiki/pie/PaceEnclosuresAndPix > > Dan > > > On 24-Jan-05, at 7:18 PM, Tim Bray wrote: > > >If there were no further discussion: Got no -1's, seems useful, needed > > >for feature parity with RSS2, will likely go in absent some > > >objections. -Tim > > -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Jan 26 14:45: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 OAA05346 for ; Wed, 26 Jan 2005 14:45: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 j0QJYB0u039756; Wed, 26 Jan 2005 11:34: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 j0QJYBr2039755; Wed, 26 Jan 2005 11:34:11 -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 j0QJYAo4039748 for ; Wed, 26 Jan 2005 11:34:10 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so163150rnz for ; Wed, 26 Jan 2005 11:34: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=JsZjK8FfcHrV7I9kMk96wd2en+C/z+qZg4O4WftwdBtA9C/f6O2nc6ShbVD4ZTWHLTRB7Mvs7Xo6joCg9l+mZ2vZXX+SX/nKXnm71FyF8iI5QMlI0Acqi6PErNEO2gLuKK85wR5Ydkf8oIxyY+fMvJXfG6xnAxSYdmG3mXrsfWQ= Received: by 10.38.26.40 with SMTP id 40mr138043rnz; Wed, 26 Jan 2005 11:34:10 -0800 (PST) Received: by 10.38.179.71 with HTTP; Wed, 26 Jan 2005 11:34:10 -0800 (PST) Message-ID: <1f2ed5cd0501261134532a639e@mail.gmail.com> Date: Wed, 26 Jan 2005 20:34:10 +0100 From: Danny Ayers Reply-To: Danny Ayers To: bob@wyman.us Subject: Re: PaceFeedLink Cc: Graham , Eric Scheid , Atom Syntax In-Reply-To: <200501261629.CLC58098@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200501261629.CLC58098@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 26 Jan 2005 11:29:03 -0500, Bob Wyman wrote: > > Graham wrote: > > The text needs something along the lines of "Atom producers MUST > > NOT expect consumers which found the document at a different > > URI to switch to requesting it from the URI specified.", or > > something less clunky. Otherwise it's going to cause all sorts > > of problems and arguments. > +1. I agree. We've found that we must take site's or file's > statements about their location or the location of related resources with a > "grain of salt."... Often, data found in things like autodiscovery resources > provides nothing more than a hint of where something might be or where it > might have been a few weeks or months ago... > If people want "re-direct" they should use the formally defined > redirection mechanisms. +1 modifications as suggested -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Jan 26 14:48: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 OAA05618 for ; Wed, 26 Jan 2005 14:48: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 j0QJdb56040740; Wed, 26 Jan 2005 11:39: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 j0QJdb73040739; Wed, 26 Jan 2005 11:39: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.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0QJdaeH040728 for ; Wed, 26 Jan 2005 11:39:36 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so163513rnz for ; Wed, 26 Jan 2005 11:39:31 -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=tfx6jYXVsIUFPeodXIiRdBItVIMyf9J+tdkuskyWJfs+oP7efQgYfjTyR6prc5+cAWNAtFXmx7TTMDu65WCUiKWpNvuAwP8P9JA3xCNJyg95J0nboypS4iyQ/n/CPOInn2RUqKNnAO0nlMmcdZWikpJFfVg0BQfeKoUxN3bC/LI= Received: by 10.38.26.40 with SMTP id 40mr140023rnz; Wed, 26 Jan 2005 11:39:31 -0800 (PST) Received: by 10.38.179.71 with HTTP; Wed, 26 Jan 2005 11:39:31 -0800 (PST) Message-ID: <1f2ed5cd050126113927d6b54b@mail.gmail.com> Date: Wed, 26 Jan 2005 20:39:31 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Julian Reschke Subject: Re: PaceIRI status Cc: Martin Duerst , Bjoern Hoehrmann , atom-syntax@imc.org In-Reply-To: <41F74CCB.3020307@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <871C1F76-6E66-11D9-9797-000A95A51C9E@textuality.com> <41F6007B.8000008@gmx.de> <6.0.0.20.2.20050125173750.041c9958@localhost> <41F649A0.7060706@gmx.de> <42194c32.136867687@smtp.bjoern.hoehrmann.de> <41F65380.7090501@gmx.de> <421d5ad6.140615437@smtp.bjoern.hoehrmann.de> <41F65D77.6060701@gmx.de> <6.0.0.20.2.20050126075033.076c5890@localhost> <41F74CCB.3020307@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1 on PaceIRI I'm a little hesitant on this because I'm not familiar with the issues, but it's something we'll probably all have to broach sometime soon. Martin seems to know what he's talking about ;-) On Wed, 26 Jan 2005 08:54:51 +0100, Julian Reschke wrote: > > Martin Duerst wrote: > > ... > > Bjoern was making a vaild, but fine, point: Because we decided to > > refer to RFC2396bis, rather than to RFC2396, we already have bought > > into the fact that RFC2396bis allows percent-encoded domain names, > > and thus essentially requires IDN support. (apart from the basic > > fact that no resolver is required to resolve all URIs or IRIs) > > ... > > OK, thanks for making me aware of this subtle change. > > > ... > > Regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Jan 26 15: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 PAA08301 for ; Wed, 26 Jan 2005 15:08: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 j0QK0Xwm042819; Wed, 26 Jan 2005 12: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 j0QK0XaE042818; Wed, 26 Jan 2005 12:00: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 j0QK0WVS042812 for ; Wed, 26 Jan 2005 12:00:32 -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 j0QK0Wdt000966 for ; Wed, 26 Jan 2005 13:00:32 -0700 (MST) Received: from xpa-fe1 (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 <0IAX00ABCWWQDO@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 26 Jan 2005 13:00:27 -0700 (MST) Received: from [192.168.1.4] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAX008JMWWQMX@mail.sun.net> for atom-syntax@imc.org; Wed, 26 Jan 2005 13:00:26 -0700 (MST) Date: Wed, 26 Jan 2005 12:00:24 -0800 From: Tim Bray Subject: Re: PaceEnclosuresAndPix status In-reply-to: <08F07334-6E70-11D9-9797-000A95A51C9E@textuality.com> 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 References: <92798DAC-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f505012417187d37ae78@mail.gmail.com> <08F07334-6E70-11D9-9797-000A95A51C9E@textuality.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT 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 Hearing no objections, I modified the Pace to say the image SHOULD have an aspect ratio of 2 (horizontal) to 1 (vertical). -Tim From owner-atom-syntax@mail.imc.org Wed Jan 26 15: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 PAA16454 for ; Wed, 26 Jan 2005 15:58: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 j0QKiCGN047663; Wed, 26 Jan 2005 12:44: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 j0QKiCw0047662; Wed, 26 Jan 2005 12:44:12 -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 j0QKiBU8047650 for ; Wed, 26 Jan 2005 12:44:11 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-223.adsl-net.finnetcom.net ([217.140.228.223]:52139 "EHLO [217.140.228.223]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228711AbVAZUoG (ORCPT ); Wed, 26 Jan 2005 22:44:06 +0200 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Atom Syntax From: Henri Sivonen Subject: Difference of TEXT and XHTML? Date: Wed, 26 Jan 2005 22:44:03 +0200 X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Quoting from draft-ietf-atompub-format-04: > 3.1.1 "type" Attribute ... > If the value is "TEXT", the content of the Text construct MUST NOT > contain child elements. Such text is intended to be presented to > humans in a readable fashion. Thus, software MAY display it using > normal text rendering techniques such as proportional fonts, > white-space collapsing, and justification. ... > 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. Receiving software which displays the content MAY use the > markup to aid in displaying it. Considering that TEXT MAY be white-space collapsed (why not SHOULD?) and XHTML allows anything that could go in div including text, isn't TEXT redundant? What's the difference between: I do not like marquee> and I do not like marquee> ? Shouldn't both render as "I do not like "? FWIW, with the exception of content, I think allowing only %inline XHTML elements would make more sense than allowing %flow. -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Wed Jan 26 15: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 PAA16461 for ; Wed, 26 Jan 2005 15: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 j0QKlWlK048074; Wed, 26 Jan 2005 12:47: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 j0QKlW6D048073; Wed, 26 Jan 2005 12:47:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0QKlUOG048056 for ; Wed, 26 Jan 2005 12:47:30 -0800 (PST) (envelope-from sjoerd@w3future.com) Received: from [10.0.0.3] (w3future.xs4all.nl [213.84.155.207]) (authenticated bits=0) by smtp-vbr6.xs4all.nl (8.12.11/8.12.11) with ESMTP id j0QKlJKQ050156; Wed, 26 Jan 2005 21:47:20 +0100 (CET) (envelope-from sjoerd@w3future.com) Message-ID: <41F801D2.2060401@w3future.com> Date: Wed, 26 Jan 2005 21:47:14 +0100 From: Sjoerd Visscher 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: PaceFeedLink References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: > On 26/1/05 2:16 AM, "Anne van Kesteren" wrote: > > >>I like the proposal in general though I wonder why an absolute URI is >>required. > > > One of the intended uses is for when a browser downloads a feed resource to > disk, and then hands that file to an atom handler application. Once that > happens, the original location context is lost. The whole point of xml:base is that an application that stores a page outside of its original context can add an xml:base to prevent losing the original location context. -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Wed Jan 26 16:29: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 QAA22270 for ; Wed, 26 Jan 2005 16:29: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 j0QLDkuB050700; Wed, 26 Jan 2005 13:13: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 j0QLDkH3050699; Wed, 26 Jan 2005 13:13:46 -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 j0QLDkAw050693 for ; Wed, 26 Jan 2005 13:13:46 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 77630 invoked by uid 17064); 26 Jan 2005 21:13:46 -0000 Received: from unknown (HELO [192.168.0.5]) ([83.112.229.233]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 26 Jan 2005 21:13:46 -0000 In-Reply-To: <1f2ed5cd05012611163deb9672@mail.gmail.com> References: <893856C5-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f50501241659610acb49@mail.gmail.com> <1742148530.20050125021028@djpowell.net> <1f2ed5cd05012611163deb9672@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1f8df8f84b530278821f37c506c25391@bblfish.net> Content-Transfer-Encoding: 7bit Cc: danbri@w3.org, atom-syntax@imc.org, David Powell From: Henry Story Subject: Re: PaceExtensionConstruct status Date: Wed, 26 Jan 2005 22:13:34 +0100 To: Danny Ayers 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 26 Jan 2005, at 20:16, Danny Ayers wrote: > I believe Henry's got most of an RDF/OWL model worked out - perhaps he > could be persuaded to post it to the Wiki for nitpicking..? Yes, please do nitpick :-) It's the AtomOWL [1] wiki page. Perhaps there is a better way of presenting it, that would make it easier to nitpick. > Correct me if I'm wrong - the tricky bit relating to content > datatypes still needs figuring out, along with a couple of > inconsistencies/weird structures within Atom. Yes. That is indeed tricky, and probably a little beyond my present skill set. I thought someone said on this list recently that it was possible perhaps using xmlschema and treating the content as a special literal. I just can't find the reference anymore. Henry Story [1] http://www.intertwingly.net/wiki/pie/AtomOWL From owner-atom-syntax@mail.imc.org Wed Jan 26 16:31: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 QAA22558 for ; Wed, 26 Jan 2005 16:31: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 j0QLIMbk051418; Wed, 26 Jan 2005 13: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 j0QLIMbR051417; Wed, 26 Jan 2005 13:18:22 -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 j0QLILXA051407 for ; Wed, 26 Jan 2005 13:18:21 -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 j0QLILdt025801 for ; Wed, 26 Jan 2005 14:18:21 -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 <0IAY00AQV0IKDO@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 26 Jan 2005 14:18:20 -0700 (MST) Received: from [192.168.1.4] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAY006L20IJ44@mail.sun.net> for atom-syntax@imc.org; Wed, 26 Jan 2005 14:18:20 -0700 (MST) Date: Wed, 26 Jan 2005 13:18:17 -0800 From: Tim Bray Subject: Re: Difference of TEXT and XHTML? In-reply-to: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> To: Henri Sivonen 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: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 26, 2005, at 12:44 PM, Henri Sivonen wrote: > What's the difference between: > I do not like > marquee> > and > I do not like > marquee> > ? > > Shouldn't both render as "I do not like "? Yeah, but if you wanted to have 'not' in bold: I do not like <marquee> (can't do it) I do <b>not</b> like &lt;marquee> I do <b>not</b> like <marquee> (Hey, an example like that might be helpful in the spec.) > FWIW, with the exception of content, I think allowing only %inline > XHTML elements would make more sense than allowing %flow. Anyone else pro or con on this one? -Tim From owner-atom-syntax@mail.imc.org Wed Jan 26 16:42: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 QAA23342 for ; Wed, 26 Jan 2005 16:42: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 j0QLZ3lh052758; Wed, 26 Jan 2005 13:35: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 j0QLZ3r1052757; Wed, 26 Jan 2005 13:35:03 -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 j0QLZ2Kq052739 for ; Wed, 26 Jan 2005 13:35: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 (sccrmhc12) with SMTP id <2005012621345601200g8ik3e>; Wed, 26 Jan 2005 21:34:57 +0000 Date: Wed, 26 Jan 2005 14:34:57 -0700 Subject: Re: Difference of TEXT and XHTML? 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: <1FC22C75-6FE2-11D9-8440-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, January 26, 2005, at 02:18 PM, Tim Bray wrote: > I do not like <marquee> (can't do it) > I do <b>not</b> like &lt;marquee> > I do <b>not</b> like <marquee> > The last one needs to be something like the following, right? <div xmlns="http://www.w3.org/1999/xhtml">I do <b>not</b> like <marquee></div> From owner-atom-syntax@mail.imc.org Wed Jan 26 16:44: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 QAA23496 for ; Wed, 26 Jan 2005 16:44: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 j0QLVjId052431; Wed, 26 Jan 2005 13:31: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 j0QLVjDZ052430; Wed, 26 Jan 2005 13:31:45 -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 j0QLViYf052407 for ; Wed, 26 Jan 2005 13:31:45 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-223.adsl-net.finnetcom.net ([217.140.228.223]:52190 "EHLO [217.140.228.223]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228829AbVAZVb0 (ORCPT ); Wed, 26 Jan 2005 23:31:26 +0200 In-Reply-To: References: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henri Sivonen Subject: Re: Difference of TEXT and XHTML? Date: Wed, 26 Jan 2005 23:31:24 +0200 To: Tim Bray X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 26, 2005, at 23:18, Tim Bray wrote: > On Jan 26, 2005, at 12:44 PM, Henri Sivonen wrote: >> What's the difference between: >> I do not like >> marquee> >> and >> I do not like >> marquee> >> ? >> >> Shouldn't both render as "I do not like "? > > Yeah, but if you wanted to have 'not' in bold: > > I do not like <marquee> (can't do it) > I do <b>not</b> like &lt;marquee> > I do <b>not</b> like <marquee> But if you can always substitute type='TEXT' with type='XHTML' but not the other way round, what's the point of having type='TEXT' in the spec? -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Wed Jan 26 16:46: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 QAA23618 for ; Wed, 26 Jan 2005 16:46: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 j0QLeHuA053533; Wed, 26 Jan 2005 13:40: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 j0QLeH6o053530; Wed, 26 Jan 2005 13:40:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0QLeGmA053513 for ; Wed, 26 Jan 2005 13:40:17 -0800 (PST) (envelope-from lgonze@panix.com) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail3.panix.com (Postfix) with ESMTP id 632A5981B2; Wed, 26 Jan 2005 16:40:13 -0500 (EST) Received: from localhost (lgonze@localhost) by panix2.panix.com (8.11.6p3/8.8.8/PanixN1.1) with ESMTP id j0QLeDn05759; Wed, 26 Jan 2005 16:40:13 -0500 (EST) Date: Wed, 26 Jan 2005 11:40:13 -1000 (HST) From: Lucas Gonze Reply-To: lucas@gonze.com To: Tim Bray Cc: Henri Sivonen , Atom Syntax Subject: Re: Difference of TEXT and XHTML? In-Reply-To: Message-ID: References: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > On Jan 26, 2005, at 12:44 PM, Henri Sivonen wrote: >> FWIW, with the exception of content, I think allowing only %inline XHTML >> elements would make more sense than allowing %flow. On Wed, 26 Jan 2005, Tim Bray wrote: > Anyone else pro or con on this one? -Tim This has elegance and is intuitively appealing. However it would open up a can of worms with styling. CSS must go in the document head. Inline HTML or XHTML probably doesn't have access to the document head. XHTML doesn't have styling elements like , HTML does. So there would have to be a provision to get CSS into the document head, which adds complexity instead of subtracting it. One thing -- my knowledge of XHTML is shallow, so I may be missing a solution to styling that doesn't require HTML. - Lucas Gonze From owner-atom-syntax@mail.imc.org Wed Jan 26 16:55: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 QAA24533 for ; Wed, 26 Jan 2005 16:55: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 j0QLkO9H054109; Wed, 26 Jan 2005 13:46: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 j0QLkOIP054108; Wed, 26 Jan 2005 13:46: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 j0QLkNCw054102 for ; Wed, 26 Jan 2005 13:46:23 -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 j0QLkNVu002276 for ; Wed, 26 Jan 2005 14:46:23 -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 <0IAY00AE91TA0W@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 26 Jan 2005 14:46:22 -0700 (MST) Received: from [192.168.1.6] ([129.150.25.28]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAY006711T944@mail.sun.net> for atom-syntax@imc.org; Wed, 26 Jan 2005 14:46:22 -0700 (MST) Date: Wed, 26 Jan 2005 13:46:19 -0800 From: Tim Bray Subject: Re: Difference of TEXT and XHTML? In-reply-to: To: Henri Sivonen 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: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 26, 2005, at 1:31 PM, Henri Sivonen wrote: > But if you can always substitute type='TEXT' with type='XHTML' but not > the other way round, what's the point of having type='TEXT' in the > spec? With type='TEXT' you know it's not going to contain any (X)HTML formatting, so you don't have to invoke your (X)HTML renderer. -Tim From owner-atom-syntax@mail.imc.org Wed Jan 26 17:05: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 RAA25411 for ; Wed, 26 Jan 2005 17:05: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 j0QLrnwY054699; Wed, 26 Jan 2005 13:53: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 j0QLrnD6054698; Wed, 26 Jan 2005 13:53: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 j0QLrmBq054691 for ; Wed, 26 Jan 2005 13:53:48 -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 1Ctv6Y-0001Q7-G2; Wed, 26 Jan 2005 21:53:38 +0000 Message-ID: <41F81163.20302@franklinmint.fm> Date: Wed, 26 Jan 2005 16:53:39 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henri Sivonen CC: Tim Bray , Atom Syntax Subject: Re: Difference of TEXT and XHTML? References: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> 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 Henri Sivonen wrote: > But if you can always substitute type='TEXT' with type='XHTML' but not > the other way round, what's the point of having type='TEXT' in the spec? You can't. I&nbsp;do&nbsp;not&nbsp;like&nbsp;<marquee> I do not like ... Robert Sayre From owner-atom-syntax@mail.imc.org Wed Jan 26 17:09: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 RAA27132 for ; Wed, 26 Jan 2005 17:09: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 j0QM2M1F055357; Wed, 26 Jan 2005 14:02: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 j0QM2MkX055356; Wed, 26 Jan 2005 14:02:22 -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.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0QM2LQs055339 for ; Wed, 26 Jan 2005 14:02:21 -0800 (PST) (envelope-from petite.abeille@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so320148wri for ; Wed, 26 Jan 2005 14:02:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer; b=i1tgYsV9Irf+BPH96vcWzuCwVt+JZZc2oRKYVEEqtL1njBnSxG0k5CmdRC4Q4lXTrws/EkT5sVyHeGgKw9NhK5xn30DhGCeTQWk1T4XVME6KBMi3LmdOV95KvtTkaWTQddpKfvQbDtLGXeW63tiA9gzlbuzYy3IzwZ1MH7umjs0= Received: by 10.54.31.70 with SMTP id e70mr188683wre; Wed, 26 Jan 2005 14:02:10 -0800 (PST) Received: from ?10.0.1.19? ([62.167.131.155]) by smtp.gmail.com with ESMTP id 65sm37370wra.2005.01.26.14.02.09; Wed, 26 Jan 2005 14:02:10 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: PA Subject: Re: Difference of TEXT and XHTML? Date: Wed, 26 Jan 2005 23:02: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 On Jan 26, 2005, at 22:46, Tim Bray wrote: > With type='TEXT' you know it's not going to contain any (X)HTML > formatting, so you don't have to invoke your (X)HTML renderer. -Tim Newbie question: Why is "type" not a MIME type already? As in an anchor tag for example? http://www.w3.org/TR/REC-html40/struct/links.html#adef-type-A I'm sure there must be a very valid reason for such unfortunate discrepancy, but at first glance I cannot see it: 3.1.1 "type" Attribute Note that MIME media types [RFC2045] are not acceptable values for the "type" attribute. 3.5.2 "type" Attribute Link constructs MAY have a type attribute, whose value MUST conform to the syntax of a MIME media type [RFC2045]. Cheers -- PA http://alt.textdrive.com/ From owner-atom-syntax@mail.imc.org Wed Jan 26 17:36: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 RAA28942 for ; Wed, 26 Jan 2005 17:36: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 j0QMOkd2057340; Wed, 26 Jan 2005 14:24: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 j0QMOkaA057339; Wed, 26 Jan 2005 14:24:46 -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 j0QMOjaK057331 for ; Wed, 26 Jan 2005 14:24:46 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-223.adsl-net.finnetcom.net ([217.140.228.223]:52282 "EHLO [217.140.228.223]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228711AbVAZWYk (ORCPT ); Thu, 27 Jan 2005 00:24:40 +0200 In-Reply-To: <41F81163.20302@franklinmint.fm> References: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> <41F81163.20302@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <10F2B6B0-6FE9-11D9-B1FA-003065B8CF0E@iki.fi> Content-Transfer-Encoding: 7bit Cc: Atom Syntax , Tim Bray From: Henri Sivonen Subject: Re: Difference of TEXT and XHTML? Date: Thu, 27 Jan 2005 00:24:38 +0200 To: Robert Sayre X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 26, 2005, at 23:53, Robert Sayre wrote: > Henri Sivonen wrote: > >> But if you can always substitute type='TEXT' with type='XHTML' but >> not the other way round, what's the point of having type='TEXT' in >> the spec? > > > You can't. > > type='TEXT'>I&nbsp;do&nbsp;not&nbsp;like&nbsp;< > marquee> > I do not like ... Sorry, I don't understand what your example is demonstrating. How would the above be different from: I&nbsp;do&nbsp;not&nbsp;like&nbsp;< marquee> I do not like ... ? -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Wed Jan 26 17: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 RAA29643 for ; Wed, 26 Jan 2005 17: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 j0QMcV8Q058102; Wed, 26 Jan 2005 14: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 j0QMcVii058101; Wed, 26 Jan 2005 14:38: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 j0QMcU9G058085 for ; Wed, 26 Jan 2005 14:38:30 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-223.adsl-net.finnetcom.net ([217.140.228.223]:52297 "EHLO [217.140.228.223]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228710AbVAZWiO (ORCPT ); Thu, 27 Jan 2005 00:38:14 +0200 In-Reply-To: References: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henri Sivonen Subject: Re: Difference of TEXT and XHTML? Date: Thu, 27 Jan 2005 00:38:12 +0200 To: Tim Bray X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 26, 2005, at 23:46, Tim Bray wrote: > On Jan 26, 2005, at 1:31 PM, Henri Sivonen wrote: > >> But if you can always substitute type='TEXT' with type='XHTML' but >> not the other way round, what's the point of having type='TEXT' in >> the spec? > > With type='TEXT' you know it's not going to contain any (X)HTML > formatting, so you don't have to invoke your (X)HTML renderer. Is it useful to support that kind of optimization on the format level? I would expect a feed renderer to use the same rendering approach for all titles for visual consistency. Even if a renderer chose to make optimizations, surely it could check for element children itself (which would be more robust than trusting the feed generator). -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Wed Jan 26 17: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 RAA00058 for ; Wed, 26 Jan 2005 17:52: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 j0QMgvJ6058529; Wed, 26 Jan 2005 14:42: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 j0QMgvYI058528; Wed, 26 Jan 2005 14:42: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 j0QMcU9I058085 for ; Wed, 26 Jan 2005 14:42:57 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-223.adsl-net.finnetcom.net ([217.140.228.223]:52317 "EHLO [217.140.228.223]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228710AbVAZWm4 (ORCPT ); Thu, 27 Jan 2005 00:42:56 +0200 In-Reply-To: References: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9E7FE4C4-6FEB-11D9-B1FA-003065B8CF0E@iki.fi> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henri Sivonen Subject: Re: Difference of TEXT and XHTML? Date: Thu, 27 Jan 2005 00:42:55 +0200 To: lucas@gonze.com X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 26, 2005, at 23:40, Lucas Gonze wrote: > Inline HTML or XHTML probably doesn't have access to the document head. Neither has %flow. > XHTML doesn't have styling elements like , HTML does. Both XHTML 1.0 Transitional and HTML 4.01 Transitional have . Neither XHTML 1.0 Strict nor HTML 4.01 Strict has . > So there would have to be a provision to get CSS into the document > head, which adds complexity instead of subtracting it. Why would there have to be a method for shipping CSS for titles and similar "text constructs"? -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Wed Jan 26 17:55: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 RAA00206 for ; Wed, 26 Jan 2005 17:55: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 j0QMjIpU058703; Wed, 26 Jan 2005 14: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 j0QMjIon058702; Wed, 26 Jan 2005 14: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 j0QMjHBY058696 for ; Wed, 26 Jan 2005 14:45: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 1CtvuU-0001lr-4W; Wed, 26 Jan 2005 22:45:14 +0000 Message-ID: <41F81D7C.9010402@franklinmint.fm> Date: Wed, 26 Jan 2005 17:45:16 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henri Sivonen CC: Atom Syntax , Tim Bray Subject: Re: Difference of TEXT and XHTML? References: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> <41F81163.20302@franklinmint.fm> <10F2B6B0-6FE9-11D9-B1FA-003065B8CF0E@iki.fi> In-Reply-To: <10F2B6B0-6FE9-11D9-B1FA-003065B8CF0E@iki.fi> 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 Henri Sivonen wrote: > > On Jan 26, 2005, at 23:53, Robert Sayre wrote: > >> Henri Sivonen wrote: >> >>> But if you can always substitute type='TEXT' with type='XHTML' but >>> not the other way round, what's the point of having type='TEXT' in >>> the spec? >> >> >> >> You can't. >> >> > type='TEXT'>I&nbsp;do&nbsp;not&nbsp;like&nbsp;< >> marquee> >> I do not like ... > > > Sorry, I don't understand what your example is demonstrating. > > How would the above be different from: > type='XHTML'>I&nbsp;do&nbsp;not&nbsp;like&nbsp;< > marquee> > I do not like ... Oop, sorry. I pasted the first example in from one of the other times this has cropped up. I do not like ... I do not like ... Well I'll be damned. The spec says whitespace collapsing is allowed. But guess what, "TEXT" is *never* coming out of the spec, because it will eventually become impossible to write something that looks like markup if we don't have it. If we were to choose between the two, we should eliminate XHTML. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Jan 26 18:06: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 SAA01199 for ; Wed, 26 Jan 2005 18:06: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 j0QMtGd5059543; Wed, 26 Jan 2005 14:55: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 j0QMtGXD059542; Wed, 26 Jan 2005 14:55:16 -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 j0QMtFvn059531 for ; Wed, 26 Jan 2005 14:55:15 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-223.adsl-net.finnetcom.net ([217.140.228.223]:52346 "EHLO [217.140.228.223]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228711AbVAZWzJ (ORCPT ); Thu, 27 Jan 2005 00:55:09 +0200 In-Reply-To: <41F81D7C.9010402@franklinmint.fm> References: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> <41F81163.20302@franklinmint.fm> <10F2B6B0-6FE9-11D9-B1FA-003065B8CF0E@iki.fi> <41F81D7C.9010402@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5373367C-6FED-11D9-B1FA-003065B8CF0E@iki.fi> Content-Transfer-Encoding: 7bit Cc: Atom Syntax , Tim Bray From: Henri Sivonen Subject: Re: Difference of TEXT and XHTML? Date: Thu, 27 Jan 2005 00:55:08 +0200 To: Robert Sayre X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 27, 2005, at 00:45, Robert Sayre wrote: > But guess what, "TEXT" is *never* coming out of the spec, because it > will eventually become impossible to write something that looks like > markup if we don't have it. How so? What does type='TEXT' make possible to write that type='XHTML' with a single text node does not make possible to write? -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Wed Jan 26 18:54: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 SAA04638 for ; Wed, 26 Jan 2005 18:54: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 j0QNgst3064247; Wed, 26 Jan 2005 15:42: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 j0QNgsUC064246; Wed, 26 Jan 2005 15:42: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 j0QNgrJT064221 for ; Wed, 26 Jan 2005 15:42: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); Thu, 27 Jan 2005 12:43:03 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 27 Jan 2005 10:42:19 +1100 Subject: Re: PaceFeedLink From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <41F801D2.2060401@w3future.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 27/1/05 7:47 AM, "Sjoerd Visscher" wrote: > The whole point of xml:base is that an application that stores a page > outside of its original context can add an xml:base to prevent losing > the original location context. browsers don't. all they know is here is a URL to a resource, and here is a HTTP header which says the content is best handled by some other application, so it then saves the resource to disk and tells the other application to get a grip. It doesn't have to understand the content to do this, let alone munge the content. e. From owner-atom-syntax@mail.imc.org Wed Jan 26 19:13: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 TAA06395 for ; Wed, 26 Jan 2005 19:12: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 j0QNmFsY064693; Wed, 26 Jan 2005 15: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 j0QNmFlm064692; Wed, 26 Jan 2005 15:48:15 -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 j0QNmDgR064683 for ; Wed, 26 Jan 2005 15:48:14 -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, 27 Jan 2005 12:48:53 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 27 Jan 2005 10:48:10 +1100 Subject: Re: Difference of TEXT and XHTML? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <10F2B6B0-6FE9-11D9-B1FA-003065B8CF0E@iki.fi> 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 27/1/05 9:24 AM, "Henri Sivonen" wrote: > Sorry, I don't understand what your example is demonstrating. > > How would the above be different from: > type='XHTML'>I&nbsp;do&nbsp;not&nbsp;like&nbsp;< > marquee> > I do not like ... try instead this example "I <3 Huckabees"... e. From owner-atom-syntax@mail.imc.org Wed Jan 26 20:33: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 UAA14995 for ; Wed, 26 Jan 2005 20:33: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 j0R13tHr071595; Wed, 26 Jan 2005 17:03: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 j0R13tKR071594; Wed, 26 Jan 2005 17:03: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 j0R13sXJ071585 for ; Wed, 26 Jan 2005 17:03: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 j0R13192027646; Thu, 27 Jan 2005 01:03:07 GMT In-Reply-To: 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) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-18--368438214; protocol="application/pkcs7-signature" Message-Id: <308D49DC-6FFF-11D9-9153-000A95DC3D90@mac.com> Cc: Atom Syntax From: Graham Subject: Re: PaceEnclosuresAndPix status Date: Thu, 27 Jan 2005 01:03:00 +0000 To: Tim Bray X-Mailer: Apple Mail (2.619) 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--368438214 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 26 Jan 2005, at 8:00 pm, Tim Bray wrote: > Hearing no objections, I modified the Pace to say the image SHOULD > have an aspect ratio of 2 (horizontal) to 1 (vertical). -Tim What's our story on favicons? Quite a few programs support them and most presumably do it by guessing the URI from the feed URI (or possibly downloading the home page and looking for the URI there). I think it's a hole in RSS that needs plugging by us. Graham --Apple-Mail-18--368438214 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 9w0BCQUxDxcNMDUwMTI3MDEwMzAwWjAjBgkqhkiG9w0BCQQxFgQUG4Ux2m5WpwWS9/xSU3gfpz/r VBsweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEARAzluaLMSTrV+cv7r8ll0cLG 5thHyW3MW5g6HoIHGP43oV0x29+C9hXXoYWujGhq/v/D8AKO8Hr8DJonr2MM3+/GsS9AmgrWSwX7 QdnUvofdE6fGPXtIoM1lkXkokWZ3dUsdO1jhUwxk/en8QlGCTYspzdlLX3aElttQqqgzkljTJvy+ 5zX9uWNEhV86NCWVfveixHNcw9gczrgKTBaoKzKy1DMnbv7NaSU4WE9lV7zEZVcUhAr0Mlfrxquw diWLkXHKvZINDASD5TsABmQJRnzS5lLXfXU3YcWPd6PbNE5QhzK9ZAfLbn9VwXn4ngzHOm76rkaj rZjO+nsBB5okoQAAAAAAAA== --Apple-Mail-18--368438214-- From owner-atom-syntax@mail.imc.org Wed Jan 26 21:12: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 VAA19124 for ; Wed, 26 Jan 2005 21:12: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 j0R1tPNO076257; Wed, 26 Jan 2005 17: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 j0R1tPqs076256; Wed, 26 Jan 2005 17:55:25 -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 j0R1tORQ076239 for ; Wed, 26 Jan 2005 17:55:24 -0800 (PST) (envelope-from brent@ranchero.com) Received: from [192.168.0.3] (c-67-171-27-118.client.comcast.net[67.171.27.118]) by comcast.net (sccrmhc13) with SMTP id <2005012701550601600hd9ote>; Thu, 27 Jan 2005 01:55:19 +0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <308D49DC-6FFF-11D9-9153-000A95DC3D90@mac.com> 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> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <653B7DE8-7006-11D9-BA76-000A95CA7396@ranchero.com> Content-Transfer-Encoding: 7bit From: Brent Simmons Subject: Re: PaceEnclosuresAndPix status Date: Wed, 26 Jan 2005 17:54:35 -0800 To: Atom Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 26, 2005, at 5:03 PM, Graham wrote: > On 26 Jan 2005, at 8:00 pm, Tim Bray wrote: > >> Hearing no objections, I modified the Pace to say the image SHOULD >> have an aspect ratio of 2 (horizontal) to 1 (vertical). -Tim > > What's our story on favicons? Quite a few programs support them and > most presumably do it by guessing the URI from the feed URI (or > possibly downloading the home page and looking for the URI there). I > think it's a hole in RSS that needs plugging by us. I agree with that. It's something many feed producers care about -- I get email just about every day asking how to make a favicon appear in my software. And I always wish I could say that there's a way to specify it in the feed. I would favor specifying that favicons should be 16 x 16, or at least that they should be square. -Brent From owner-atom-syntax@mail.imc.org Wed Jan 26 21:15: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 VAA19366 for ; Wed, 26 Jan 2005 21:15: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 j0R23d2i077257; Wed, 26 Jan 2005 18:03: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 j0R23djT077256; Wed, 26 Jan 2005 18:03:39 -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 j0R23c65077248 for ; Wed, 26 Jan 2005 18:03:38 -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 j0R23cdt019667 for ; Wed, 26 Jan 2005 19:03:38 -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 <0IAY00A50DQ10W@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 26 Jan 2005 19:03:38 -0700 (MST) Received: from [192.168.1.17] ([216.113.201.159]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAY0058IDQ1UN@mail.sun.net> for atom-syntax@imc.org; Wed, 26 Jan 2005 19:03:37 -0700 (MST) Date: Wed, 26 Jan 2005 18:03:34 -0800 From: Tim Bray Subject: Re: PaceEnclosuresAndPix status In-reply-to: <308D49DC-6FFF-11D9-9153-000A95DC3D90@mac.com> To: Graham 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: <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> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 26, 2005, at 5:03 PM, Graham wrote: > What's our story on favicons? Quite a few programs support them and > most presumably do it by guessing the URI from the feed URI (or > possibly downloading the home page and looking for the URI there). I > think it's a hole in RSS that needs plugging by us. As far as I know, aggregators are using the same favicon that web browsers are. This whole thing is a mess, there's even an official W3C TAG issue for it (http://www.w3.org/2001/tag/issues.html#siteData-36). Can we please leave it stinking by the side of the road for someone else to clean up? -Tim From owner-atom-syntax@mail.imc.org Wed Jan 26 21:40: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 VAA20636 for ; Wed, 26 Jan 2005 21:40: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 j0R2P1aK079972; Wed, 26 Jan 2005 18:25: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 j0R2P1mJ079971; Wed, 26 Jan 2005 18:25: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 j0R2P0Nv079961 for ; Wed, 26 Jan 2005 18:25: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 j0R2P0dt000076 for ; Wed, 26 Jan 2005 19:25:00 -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 <0IAY00ATCEPN0W@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 26 Jan 2005 19:25:00 -0700 (MST) Received: from [192.168.1.17] ([216.113.201.159]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAY005HDEPNUN@mail.sun.net> for atom-syntax@imc.org; Wed, 26 Jan 2005 19:24:59 -0700 (MST) Date: Wed, 26 Jan 2005 18:24:57 -0800 From: Tim Bray Subject: Re: PaceEnclosuresAndPix status In-reply-to: <653B7DE8-7006-11D9-BA76-000A95CA7396@ranchero.com> To: Brent Simmons 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: <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-Transfer-Encoding: 7BIT On Jan 26, 2005, at 5:54 PM, Brent Simmons wrote: > I agree with that. It's something many feed producers care about -- I > get email just about every day asking how to make a favicon appear in > my software. And I always wish I could say that there's a way to > specify it in the feed. > > I would favor specifying that favicons should be 16 x 16, or at least > that they should be square. Uh, the way browsers do it is just like the way robots.txt works. They do a GET on "/favicon.ico", hardwired path, and (at least some of them) just silently ignore it if it's not 16x16. This sucks (just like /robots.txt sucks) because if you have multiple "sites" on the same host you're hosed. This is *not* just an RSS/syndication problem, it's bigger, and I don't think we own it. -Tim From owner-atom-syntax@mail.imc.org Wed Jan 26 21:52: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 VAA21350 for ; Wed, 26 Jan 2005 21:52: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 j0R2dX8D081027; Wed, 26 Jan 2005 18:39: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 j0R2dXtS081026; Wed, 26 Jan 2005 18:39:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [69.20.61.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0R2dWei081008 for ; Wed, 26 Jan 2005 18:39:32 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [10.254.1.82] (216-31-236-219.cust.telepacific.net [216.31.236.219]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.10) with ESMTP id j0R2dMva015840; Wed, 26 Jan 2005 21:39:23 -0500 Message-ID: <41F8545B.8070801@intertwingly.net> Date: Wed, 26 Jan 2005 21:39:23 -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: Danny Ayers , atom-syntax@imc.org Subject: Re: PaceAttributesNamespace is *not* about syntax! References: <1f2ed5cd05012602474fc907a1@mail.gmail.com> <41F7A320.9020906@intertwingly.net> <8631b39ab59dd87f9ad947318c513654@bblfish.net> In-Reply-To: <8631b39ab59dd87f9ad947318c513654@bblfish.net> 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 Henry Story wrote: > > On 26 Jan 2005, at 15:03, Sam Ruby wrote: > >> [...] >> But, now lets examine the statement proposed in >> PaceAttributeNamespace. It essentially alerts producers of something >> that that they need to be aware of. Now a quesion: what do they need >> do different with the knowledge that the RDF mapping does this? >> >> I would assert the answer to this question is nothing. Meaning that >> this particular statement is not needed. Again, no issue with the >> mapping. No issue with describing the mapping alongside with the >> actual mapping. > > I think your assertion is wrong. If they are consuming or producing > extended Atom [1] > they will know exactly what these extensions are referring to. It won't > affect in the least consumers of simple, non extended Atom, but it will > greatly > help consumers and producers of extended atom. > > Now if you don't care about making their lives easier, then you have > nothing > to worry about in this pace. If you do, like I and many others, then > this will > be very helpful. It seems to me that you are both misunderstanding and mischaracterizing what I am saying. Furthermore, in other emails, I sense a confusion between RDF (which is a model) and RDF/XML (which is a syntax). I am in favor of AtomAsRDF (as a was to model this data). I am opposed to AtomAsRDFXML (as a syntax for expressing this model). If anybody is up to the task, I am for inclusion of prose into the standard describing how one is to interpret Atom feeds as RDF. Any such mechanism that accomplishes this will, by necessity, need to specify what namespace is used in the URIs used to define relationships. PaceAttributeNamespace does not do that. All it says is is that a given namespace may be used. For what purpose such a statement is made is entirely unclear. By contrast, a precise statement to the effect of how RDF aware tools MUST interpret Atom feeds if they are to interoperate is both clear and useful. - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Jan 26 21:52: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 VAA21368 for ; Wed, 26 Jan 2005 21: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 j0R2egqH081201; Wed, 26 Jan 2005 18:40: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 j0R2egZZ081200; Wed, 26 Jan 2005 18:40:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [69.20.61.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0R2efHg081186 for ; Wed, 26 Jan 2005 18:40:41 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [10.254.1.82] (216-31-236-219.cust.telepacific.net [216.31.236.219]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.10) with ESMTP id j0R2eQTQ015966; Wed, 26 Jan 2005 21:40:27 -0500 Message-ID: <41F8549C.3000904@intertwingly.net> Date: Wed, 26 Jan 2005 21:40:28 -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: Tim Bray , Atom Syntax Subject: Re: Difference of TEXT and XHTML? References: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> In-Reply-To: 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 Henri Sivonen wrote: > > On Jan 26, 2005, at 23:46, Tim Bray wrote: > >> On Jan 26, 2005, at 1:31 PM, Henri Sivonen wrote: >> >>> But if you can always substitute type='TEXT' with type='XHTML' but >>> not the other way round, what's the point of having type='TEXT' in >>> the spec? >> >> With type='TEXT' you know it's not going to contain any (X)HTML >> formatting, so you don't have to invoke your (X)HTML renderer. > > Is it useful to support that kind of optimization on the format level? I > would expect a feed renderer to use the same rendering approach for all > titles for visual consistency. Even if a renderer chose to make > optimizations, surely it could check for element children itself (which > would be more robust than trusting the feed generator). I'm not so concerned about the optimization. But having observed quite a number of people tripping over double escaping rules in various flavors of RSS, I very much like having a very conservative default of TEXT. And then for those who wish to get more adventurous, there are two choices: XHTML (compact, clear, but must be well formed), and double escaped HTML (verbose, error prone, but can handle arbitrary content). - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Jan 26 21:54: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 VAA21438 for ; Wed, 26 Jan 2005 21:54: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 j0R2e7cj081125; Wed, 26 Jan 2005 18:40: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 j0R2e6hx081124; Wed, 26 Jan 2005 18:40:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [69.20.61.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0R2e5P6081117 for ; Wed, 26 Jan 2005 18:40:05 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [10.254.1.82] (216-31-236-219.cust.telepacific.net [216.31.236.219]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.10) with ESMTP id j0R2e0Mu015900; Wed, 26 Jan 2005 21:40:00 -0500 Message-ID: <41F85481.4050004@intertwingly.net> Date: Wed, 26 Jan 2005 21:40: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: Robert Sayre CC: Anne van Kesteren , atom-syntax@imc.org Subject: Re: Issues with draft-ietf-atompub-format-04 References: <41F60A5C.1060308@annevankesteren.nl> <41F6DE44.8020906@franklinmint.fm> In-Reply-To: <41F6DE44.8020906@franklinmint.fm> 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 Robert Sayre wrote: > >> * 3.5.1 "rel" Attribute >> >> Why are the only values defined "alternate" and "related"? I have >> implemented "via" for a long time on my personal weblog and some >> aggregators have even implemented support for it. I consider it to be >> quite useful. > > Write a Pace. I would support it. Yes, please. - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Jan 26 21:54: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 VAA21500 for ; Wed, 26 Jan 2005 21:54: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 j0R2dbbS081039; Wed, 26 Jan 2005 18:39: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 j0R2dbda081038; Wed, 26 Jan 2005 18:39:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [69.20.61.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0R2dZs0081031 for ; Wed, 26 Jan 2005 18:39:36 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [10.254.1.82] (216-31-236-219.cust.telepacific.net [216.31.236.219]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.10) with ESMTP id j0R2dWql015859; Wed, 26 Jan 2005 21:39:34 -0500 Message-ID: <41F85466.7070005@intertwingly.net> Date: Wed, 26 Jan 2005 21:39:34 -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: Martin Duerst CC: =?UTF-8?B?QXNiau+/vW4gVWxzYmVyZw==?= , Atom Syntax Subject: Re: Questions about -04 References: <873bx6x1z1.fsf@nwalsh.com> <41E59C93.4050001@intertwingly.net> <6.0.0.20.2.20050126100322.07746e30@localhost> In-Reply-To: <6.0.0.20.2.20050126100322.07746e30@localhost> Content-Type: text/plain; charset=UTF-8; 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 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. 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. 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. 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. 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. - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Jan 26 21:56: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 VAA21589 for ; Wed, 26 Jan 2005 21:56: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 j0R2dxIw081095; Wed, 26 Jan 2005 18: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 j0R2dxWL081094; Wed, 26 Jan 2005 18:39:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [69.20.61.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0R2dwum081087 for ; Wed, 26 Jan 2005 18:39:59 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [10.254.1.82] (216-31-236-219.cust.telepacific.net [216.31.236.219]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.10) with ESMTP id j0R2dtcg015892; Wed, 26 Jan 2005 21:39:55 -0500 Message-ID: <41F8547C.3090400@intertwingly.net> Date: Wed, 26 Jan 2005 21:39:56 -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: Martin Duerst CC: Robert Sayre , Walter Underwood , Atom Syntax Subject: Re: PaceMustBeWellFormed status References: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> <9E656C44A03320C76D0142CC@diva.verity.com> <41F6AE71.7060905@franklinmint.fm> <635613EB127E90365E12AD5C@diva.verity.com> <41F6B859.6080103@franklinmint.fm> <9ED7AC6C9E0C9411A5EFEF3F@diva.verity.com> <41F6C9A3.1060600@franklinmint.fm> <6.0.0.20.2.20050126090249.0776beb8@localhost> In-Reply-To: <6.0.0.20.2.20050126090249.0776beb8@localhost> 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 Martin Duerst wrote: > > >> 5. > >> Publishers MUST NOT serve Atom feeds with a media type other than > "application/atom+xml" (registered in this Section 8 of document) or one > of the XML media types defined in RFC 3023 or its successor. In > particular, "text/plain" is never an appropriate media type for an Atom > feed. When retrieving an Atom feed served with a non-XML media type, > clients MUST reject it as non-well-formed. > > > > > >We have no business stating this. I will serve Atom feeds as > text/plain if I want them processed as text documents. > > At which time I will claim that it's no longer an Atom feed, it just > looks like one :-). The Atom spec should talk about Atom as Atom; > that somebody might want to look at the Atom document as a text document, > or even as a hex dump, isn't something we should be talking about. I agree with Martin. The feedvalidator currently declares content served as text/plain as invalid. I would very much like to keep this check, for a number of reasons. For now, I will simply state one: text/plain can be used as part of a security breach. The feedvalidator can't stop such security breaches, but can discourage widescale deployment of feeds served in this manner. If we ever got to the point where there were widescale deployment of feeds served with text/plain, then consumers would essentially be forced to be liberal. Note what I am not saying. I am not saying that applications other than the feedvalidator need to reject such feeds. Nor am I saying that you can't publish the same sequence of bytes that one would tend to find in an Atom feed with a content type of text/plain. What I am saying is that the Atom spec should allow consumers enough leeway to process such resources as non-feed (specifically, I would hope that they would process such resources as plain text). - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Jan 26 22:15: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 WAA22664 for ; Wed, 26 Jan 2005 22:15: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 j0R33BXq083562; Wed, 26 Jan 2005 19:03: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 j0R33B98083561; Wed, 26 Jan 2005 19:03:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0R33Are083554 for ; Wed, 26 Jan 2005 19:03:10 -0800 (PST) (envelope-from lgonze@panix.com) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail3.panix.com (Postfix) with ESMTP id 28689981B3; Wed, 26 Jan 2005 22:03:10 -0500 (EST) Received: from localhost (lgonze@localhost) by panix2.panix.com (8.11.6p3/8.8.8/PanixN1.1) with ESMTP id j0R33AY09836; Wed, 26 Jan 2005 22:03:10 -0500 (EST) Date: Wed, 26 Jan 2005 17:03:09 -1000 (HST) From: Lucas Gonze Reply-To: lucas@gonze.com To: Henri Sivonen Cc: lucas@gonze.com, Atom Syntax Subject: Re: Difference of TEXT and XHTML? In-Reply-To: <9E7FE4C4-6FEB-11D9-B1FA-003065B8CF0E@iki.fi> Message-ID: References: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> <9E7FE4C4-6FEB-11D9-B1FA-003065B8CF0E@iki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 27 Jan 2005, Henri Sivonen wrote: > On Jan 26, 2005, at 23:40, Lucas Gonze wrote: >> XHTML doesn't have styling elements like , HTML does. > > Both XHTML 1.0 Transitional and HTML 4.01 Transitional have . Neither > XHTML 1.0 Strict nor HTML 4.01 Strict has . Then my point is moot as long as XHTML inline content may be XHTML 1.0 Transitional. A second argument that inline XHTML may be XHTML 1.0 Transitional is that it satisfies the need for well-formed XML. >> So there would have to be a provision to get CSS into the document head, >> which adds complexity instead of subtracting it. > > Why would there have to be a method for shipping CSS for titles and similar > "text constructs"? Because having control over presentation is the main reason to format content as HTML. - Lucas Gonze From owner-atom-syntax@mail.imc.org Wed Jan 26 22:31: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 WAA23724 for ; Wed, 26 Jan 2005 22:31: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 j0R3GqYt084670; Wed, 26 Jan 2005 19:16: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 j0R3GqQ6084669; Wed, 26 Jan 2005 19:16:52 -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 j0R3GpHN084659 for ; Wed, 26 Jan 2005 19:16:51 -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 j0R3GMMo020973; Thu, 27 Jan 2005 03:16:33 GMT In-Reply-To: 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> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-19--360439011; protocol="application/pkcs7-signature" Message-Id: Cc: Atom Syntax From: Graham Subject: Re: PaceEnclosuresAndPix status Date: Thu, 27 Jan 2005 03:16:18 +0000 To: Tim Bray X-Mailer: Apple Mail (2.619) 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--360439011 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 27 Jan 2005, at 2:24 am, Tim Bray wrote: > Uh, the way browsers do it is just like the way robots.txt works. > They do a GET on "/favicon.ico", hardwired path, and (at least some of > them) just silently ignore it if it's not 16x16. This sucks (just > like /robots.txt sucks) because if you have multiple "sites" on the > same host you're hosed. This is *not* just an RSS/syndication > problem, it's bigger, and I don't think we own it. 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. Graham --Apple-Mail-19--360439011 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 9w0BCQUxDxcNMDUwMTI3MDMxNjE5WjAjBgkqhkiG9w0BCQQxFgQU4fPZUs20eRiGap/609Ctejpv y18weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAmUeXEg5PtEtEsO+ahJkXSheL d5PP5RdkyMxfoaPbjlhDfUSYcz03QmD0G/Xp61tQL08tMCkQCfkBjDm6XyTmrMxxxuaDOowzOGM0 EEaPjJ/dyBraMLAh0eVR3gRo86TEoy1xmQz7kGlzw4JnJM5y05jzeCTWfutg87KHJX3NhQzOiY2y eM+hALNBK10W21cW0NZ3OiFsxFiVQLodEJMx8eGyabtX+3W/jwI5oG0WvMTpM8dNwFdVIEcqA2CJ 0GhiIP4YEJScHl4gV99qkE7cvOFnQZ0p4n1uRlZYjAPS7QQ4ZUlIV536YJmSy7sehbtdvtFpCRtk Vh5rPtFYHWrA5gAAAAAAAA== --Apple-Mail-19--360439011-- From owner-atom-syntax@mail.imc.org Wed Jan 26 22:33: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 WAA23946 for ; Wed, 26 Jan 2005 22:33: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 j0R3L9kV085046; Wed, 26 Jan 2005 19:21: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 j0R3L9wh085045; Wed, 26 Jan 2005 19:21: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 j0R3L8nd085037 for ; Wed, 26 Jan 2005 19:21:08 -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 1Cu0DR-0003u0-Ea; Thu, 27 Jan 2005 03:21:05 +0000 Message-ID: <41F85E1E.6030706@franklinmint.fm> Date: Wed, 26 Jan 2005 22:21:02 -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: Martin Duerst , Walter Underwood , Atom Syntax Subject: Re: PaceMustBeWellFormed status References: <864D1234-6E66-11D9-9797-000A95A51C9E@textuality.com> <9E656C44A03320C76D0142CC@diva.verity.com> <41F6AE71.7060905@franklinmint.fm> <635613EB127E90365E12AD5C@diva.verity.com> <41F6B859.6080103@franklinmint.fm> <9ED7AC6C9E0C9411A5EFEF3F@diva.verity.com> <41F6C9A3.1060600@franklinmint.fm> <6.0.0.20.2.20050126090249.0776beb8@localhost> <41F8547C.3090400@intertwingly.net> In-Reply-To: <41F8547C.3090400@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: > The feedvalidator currently declares content served as text/plain as > invalid. I would very much like to keep this check, for a number of > reasons. > What I am saying is > that the Atom spec should allow consumers enough leeway to process such > resources as non-feed (specifically, I would hope that they would > process such resources as plain text). Section 2 says "Both kinds of Atom documents are specified in terms of the XML Information Set, serialised as XML 1.0 [W3C.REC-xml-20040204] and identified with the "application/atom+xml" media type. Atom Documents MUST be well-formed XML." So, Atom documents are well-formed XML identified with the Atom media type. The specification doesn't talk about other media types or ill-formed XML documents. Is there something more we can add to the specification? I don't think PaceMustBeWellFormed is it. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Jan 26 22:37: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 WAA24091 for ; Wed, 26 Jan 2005 22:37: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 j0R3PVwd085307; Wed, 26 Jan 2005 19:25: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 j0R3PVFK085306; Wed, 26 Jan 2005 19:25:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [69.20.61.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0R3PUq7085299 for ; Wed, 26 Jan 2005 19:25:30 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [10.254.1.82] (216-31-236-219.cust.telepacific.net [216.31.236.219]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.10) with ESMTP id j0R3PS35022246; Wed, 26 Jan 2005 22:25:28 -0500 Message-ID: <41F85F29.2050203@intertwingly.net> Date: Wed, 26 Jan 2005 22:25:29 -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: Brent Simmons , Atom Syntax , dtcd@mac.com Subject: Re: PaceEnclosuresAndPix status 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> In-Reply-To: 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 Tim Bray wrote: > > On Jan 26, 2005, at 5:54 PM, Brent Simmons wrote: > >> I agree with that. It's something many feed producers care about -- I >> get email just about every day asking how to make a favicon appear in >> my software. And I always wish I could say that there's a way to >> specify it in the feed. >> >> I would favor specifying that favicons should be 16 x 16, or at least >> that they should be square. > > Uh, the way browsers do it is just like the way robots.txt works. They > do a GET on "/favicon.ico", hardwired path, and (at least some of them) > just silently ignore it if it's not 16x16. This sucks (just like > /robots.txt sucks) because if you have multiple "sites" on the same host > you're hosed. This is *not* just an RSS/syndication problem, it's > bigger, and I don't think we own it. -Tim Take a look at: http://lists.w3.org/Archives/Public/www-html/2003Jun/0132.html For quite some time, my XHTML has contained the following: Question: would it be of value to people like Graham and Brent if we were to "register" this rel value for Atom feeds? - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Jan 26 22:52: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 WAA24552 for ; Wed, 26 Jan 2005 22:52: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 j0R3e2TN086422; Wed, 26 Jan 2005 19:40: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 j0R3e2iN086421; Wed, 26 Jan 2005 19:40:02 -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 j0R3e0Qa086374 for ; Wed, 26 Jan 2005 19:40:01 -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, 27 Jan 2005 16:40:10 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 27 Jan 2005 14:39:27 +1100 Subject: Re: PaceEnclosuresAndPix status From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <41F85F29.2050203@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 27/1/05 2:25 PM, "Sam Ruby" wrote: > For quite some time, my XHTML has contained the following: > > > > Question: would it be of value to people like Graham and Brent if we > were to "register" this rel value for Atom feeds? that's not "a" value. that's two @rel values, space delimited. atom:@rel doesn't allow for multiple space delimited values. e. From owner-atom-syntax@mail.imc.org Wed Jan 26 23:01: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 XAA25495 for ; Wed, 26 Jan 2005 23:01: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 j0R3mW50087006; Wed, 26 Jan 2005 19:48: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 j0R3mWLA087005; Wed, 26 Jan 2005 19:48: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 j0R3mWmG086996 for ; Wed, 26 Jan 2005 19:48:32 -0800 (PST) (envelope-from brent@ranchero.com) Received: from [192.168.0.3] (c-67-171-27-118.client.comcast.net[67.171.27.118]) by comcast.net (rwcrmhc12) with SMTP id <2005012703482601400henpde>; Thu, 27 Jan 2005 03:48:27 +0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <41F85F29.2050203@intertwingly.net> 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> <41F85F29.2050203@intertwingly.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <46730E03-7016-11D9-BA76-000A95CA7396@ranchero.com> Content-Transfer-Encoding: 7bit From: Brent Simmons Subject: Re: PaceEnclosuresAndPix status Date: Wed, 26 Jan 2005 19:48:15 -0800 To: Atom Syntax , Sam Ruby X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 26, 2005, at 7:25 PM, Sam Ruby wrote: > > Tim Bray wrote: >> On Jan 26, 2005, at 5:54 PM, Brent Simmons wrote: >>> I agree with that. It's something many feed producers care about -- >>> I get email just about every day asking how to make a favicon appear >>> in my software. And I always wish I could say that there's a way to >>> specify it in the feed. >>> >>> I would favor specifying that favicons should be 16 x 16, or at >>> least that they should be square. >> Uh, the way browsers do it is just like the way robots.txt works. >> They do a GET on "/favicon.ico", hardwired path, and (at least some >> of them) just silently ignore it if it's not 16x16. This sucks (just >> like /robots.txt sucks) because if you have multiple "sites" on the >> same host you're hosed. This is *not* just an RSS/syndication >> problem, it's bigger, and I don't think we own it. -Tim > > Take a look at: > > http://lists.w3.org/Archives/Public/www-html/2003Jun/0132.html > > For quite some time, my XHTML has contained the following: > > > > Question: would it be of value to people like Graham and Brent if we > were to "register" this rel value for Atom feeds? > > - Sam Ruby Yes, this would work for me. -Brent From owner-atom-syntax@mail.imc.org Wed Jan 26 23:13: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 XAA26468 for ; Wed, 26 Jan 2005 23:13: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 j0R3xaFE087856; Wed, 26 Jan 2005 19:59: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 j0R3xak4087855; Wed, 26 Jan 2005 19:59:36 -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 j0R3xZB8087848 for ; Wed, 26 Jan 2005 19:59:35 -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 j0R3xZVu001508 for ; Wed, 26 Jan 2005 20:59:35 -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 <0IAY00AK6J3AHV@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 26 Jan 2005 20:59:35 -0700 (MST) Received: from [192.168.1.17] ([216.113.201.159]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAY00010J3A8A@mail.sun.net> for atom-syntax@imc.org; Wed, 26 Jan 2005 20:59:34 -0700 (MST) Date: Wed, 26 Jan 2005 19:59:32 -0800 From: Tim Bray Subject: Re: PaceEnclosuresAndPix status In-reply-to: To: Graham 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: <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-Transfer-Encoding: 7BIT 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 software can easily emulate that, giving us feature parity. So what you're really requesting is a per-feed icon. Write a Pace. If you can get a few +1's quite likely nobody will stand in the way. And if it didn't get in, few hearts would be broken. -Tim From owner-atom-syntax@mail.imc.org Wed Jan 26 23:16: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 XAA26698 for ; Wed, 26 Jan 2005 23:16: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 j0R41N06087999; Wed, 26 Jan 2005 20: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 j0R41NFd087998; Wed, 26 Jan 2005 20:01: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 j0R41Mgp087991 for ; Wed, 26 Jan 2005 20:01: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 j0R41Mdt012378 for ; Wed, 26 Jan 2005 21:01: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 <0IAY00ANVJ69HV@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 26 Jan 2005 21:01:22 -0700 (MST) Received: from [192.168.1.17] ([216.113.201.159]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAY0000OJ697R@mail.sun.net> for atom-syntax@imc.org; Wed, 26 Jan 2005 21:01:21 -0700 (MST) Date: Wed, 26 Jan 2005 20:01:19 -0800 From: Tim Bray Subject: Re: PaceEnclosuresAndPix status In-reply-to: <41F85F29.2050203@intertwingly.net> To: Sam Ruby Cc: Brent Simmons , Atom Syntax , dtcd@mac.com Message-id: <19C59DB0-7018-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: <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> <41F85F29.2050203@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 26, 2005, at 7:25 PM, Sam Ruby wrote: > http://lists.w3.org/Archives/Public/www-html/2003Jun/0132.html > > For quite some time, my XHTML has contained the following: > > > > Question: would it be of value to people like Graham and Brent if we > were to "register" this rel value for Atom feeds? Heh, didn't know that. Much better than hardwiring /favicon.ico. So someone write a Pace already, it only needs 3 lines. -Tim From owner-atom-syntax@mail.imc.org Wed Jan 26 23:47: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 XAA29676 for ; Wed, 26 Jan 2005 23:47: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 j0R4cSpg093782; Wed, 26 Jan 2005 20:38: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 j0R4cSGJ093781; Wed, 26 Jan 2005 20:38:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [69.20.61.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0R4cQuO093774 for ; Wed, 26 Jan 2005 20:38:27 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [10.254.1.82] (216-31-236-219.cust.telepacific.net [216.31.236.219]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.10) with ESMTP id j0R4cO8X031331; Wed, 26 Jan 2005 23:38:25 -0500 Message-ID: <41F87041.1050301@intertwingly.net> Date: Wed, 26 Jan 2005 23:38:25 -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: PaceEnclosuresAndPix status References: In-Reply-To: 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 Eric Scheid wrote: > On 27/1/05 2:25 PM, "Sam Ruby" wrote: > >>For quite some time, my XHTML has contained the following: >> >> >> >>Question: would it be of value to people like Graham and Brent if we >>were to "register" this rel value for Atom feeds? > > that's not "a" value. that's two @rel values, space delimited. > > atom:@rel doesn't allow for multiple space delimited values. > > e. http://lists.w3.org/Archives/Public/www-html/2003Jun/0133.html - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Jan 26 23: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 XAA29714 for ; Wed, 26 Jan 2005 23: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 j0R4YgcU093166; Wed, 26 Jan 2005 20:34: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 j0R4YgD8093165; Wed, 26 Jan 2005 20:34:42 -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 j0R4Yed6093158 for ; Wed, 26 Jan 2005 20:34: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); Thu, 27 Jan 2005 17:35:20 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 27 Jan 2005 15:34:36 +1100 Subject: Re: PaceEnclosuresAndPix status From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <19C59DB0-7018-11D9-9797-000A95A51C9E@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 27/1/05 3:01 PM, "Tim Bray" wrote: >> For quite some time, my XHTML has contained the following: >> >> >> >> Question: would it be of value to people like Graham and Brent if we >> were to "register" this rel value for Atom feeds? > > Heh, didn't know that. Much better than hardwiring /favicon.ico. So > someone write a Pace already, it only needs 3 lines. -Tim do we want a way of associating a favicon with a feed? yes. does this mean we must use the element for this? is valid inside an element? e. * or whatever. From owner-atom-syntax@mail.imc.org Thu Jan 27 00:51: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 AAA04733 for ; Thu, 27 Jan 2005 00:51: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 j0R5emQ5000121; Wed, 26 Jan 2005 21:40: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 j0R5emMm000120; Wed, 26 Jan 2005 21:40: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 j0R5ehWn000104 for ; Wed, 26 Jan 2005 21:40:47 -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, 27 Jan 2005 18:41:21 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 27 Jan 2005 16:40:37 +1100 Subject: Re: PaceEnclosuresAndPix status From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <41F87041.1050301@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 27/1/05 3:38 PM, "Sam Ruby" wrote: >> atom:@rel doesn't allow for multiple space delimited values. >> >> e. > > http://lists.w3.org/Archives/Public/www-html/2003Jun/0133.html agreed, a single term @rel value is preferred. the "shortcut icon" thing is borked ... the linked favicon is used for more than just an icon for the shortcuts/bookmarks list in browsers, f'rinstance, and the resource so linked is not a "shortcut" to the linking resource, whatever that means (an html page with links to popular posts might be). so, "icon" ... or "favicon". I prefer the latter. e. From owner-atom-syntax@mail.imc.org Thu Jan 27 01:50: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 BAA08674 for ; Thu, 27 Jan 2005 01:50: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 j0R6fVD4018968; Wed, 26 Jan 2005 22: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 j0R6fU3Z018967; Wed, 26 Jan 2005 22:41:30 -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 j0R6fTfI018762 for ; Wed, 26 Jan 2005 22:41:30 -0800 (PST) (envelope-from fora@annevankesteren.nl) Received: (qmail 19501 invoked by uid 10); 27 Jan 2005 06:41:13 -0000 Received: (vexira-qq 19490-8C0B39A1 invoked from network) 27 Jan 2005 07:41:13 +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 < >; 27 Jan 2005 06:41:13 -0000 Message-ID: <41F88D0E.1060400@annevankesteren.nl> Date: Thu, 27 Jan 2005 07:41:18 +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, Tim Bray Subject: Re: Difference of TEXT and XHTML? References: <1FC22C75-6FE2-11D9-8440-003065EA6144@geckotribe.com> In-Reply-To: <1FC22C75-6FE2-11D9-8440-003065EA6144@geckotribe.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.5; VDF: 6.29.0.52; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > On Wednesday, January 26, 2005, at 02:18 PM, Tim Bray wrote: > >> I do not like <marquee> (can't do it) >> I do <b>not</b> like &lt;marquee> >> I do <b>not</b> like <marquee> >> > The last one needs to be something like the following, right? > > <div xmlns="http://www.w3.org/1999/xhtml">I do > <b>not</b> like <marquee></div> I was wondering about this as well. When you have @type['XHTML'], does it need to be in a namespace, or not? (Sounds logical, but apparently people do different things.) And which XHTML DTD has to be followed for the content model? -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Thu Jan 27 02:26: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 CAA25683 for ; Thu, 27 Jan 2005 02:26: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 j0R7Epnw033904; Wed, 26 Jan 2005 23: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 j0R7EpB5033903; Wed, 26 Jan 2005 23:14:51 -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 j0R7Eomx033814 for ; Wed, 26 Jan 2005 23:14:50 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-12.adsl-net.finnetcom.net ([217.140.228.12]:52503 "EHLO [217.140.228.12]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228772AbVA0HOg (ORCPT ); Thu, 27 Jan 2005 09:14:36 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1743E1A5-7033-11D9-B1FA-003065B8CF0E@iki.fi> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henri Sivonen Subject: Re: Difference of TEXT and XHTML? Date: Thu, 27 Jan 2005 09:14:32 +0200 To: Eric Scheid X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 27, 2005, at 01:48, Eric Scheid wrote: > try instead this example "I <3 Huckabees"... That makes no difference, either. I <3 Huckabees Only type='HTML' is different. ; Thu, 27 Jan 2005 02: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 j0R7VxD1040163; Wed, 26 Jan 2005 23:31: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 j0R7VxID040162; Wed, 26 Jan 2005 23:31:59 -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 j0R7VwuG040125 for <atom-syntax@imc.org>; Wed, 26 Jan 2005 23:31:59 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-12.adsl-net.finnetcom.net ([217.140.228.12]:52513 "EHLO [217.140.228.12]" TLS-CIPHER: <none>) by smtp2.dnainternet.net with ESMTP id S1228782AbVA0Hbx (ORCPT <rfc822;atom-syntax@imc.org>); Thu, 27 Jan 2005 09:31:53 +0200 In-Reply-To: <41F88D0E.1060400@annevankesteren.nl> References: <1FC22C75-6FE2-11D9-8440-003065EA6144@geckotribe.com> <41F88D0E.1060400@annevankesteren.nl> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <78D5DF85-7035-11D9-B1FA-003065B8CF0E@iki.fi> Content-Transfer-Encoding: 7bit Cc: Antone Roundy <antone@geckotribe.com>, atom-syntax@imc.org, Tim Bray <Tim.Bray@Sun.COM> From: Henri Sivonen <hsivonen@iki.fi> Subject: Re: Difference of TEXT and XHTML? Date: Thu, 27 Jan 2005 09:31:34 +0200 To: Anne van Kesteren <fora@annevankesteren.nl> X-Mailer: Apple Mail (2.619) 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 Jan 27, 2005, at 08:41, Anne van Kesteren wrote: > Antone Roundy wrote: >> On Wednesday, January 26, 2005, at 02:18 PM, Tim Bray wrote: >>> <title type='TEXT'>I do not like <marquee> (can't do it) >>> I do <b>not</b> like >>> &lt;marquee> >>> I do <b>not</b> like <marquee> >>> >> The last one needs to be something like the following, right? >> <div xmlns="http://www.w3.org/1999/xhtml">I do >> <b>not</b> like <marquee></div> Or, rather: I do <b xmlns="http://www.w3.org/1999/xhtml">not</b> like <marquee> > I was wondering about this as well. When you have @type['XHTML'], does > it need to be in a namespace, or not? (Sounds logical, but apparently > people do different things.) Why wouldn't it require the elements that purport to be XHTML elements to be in the XHTML namespace? I do not, however, think that it is useful to restrict type='XHTML' in the content element to have element descendants only from the XHTML namespace. Those who want to do math will mix MathML with XHTML anyway and have it render in a future non-bogotic feed reader Firefox extension (which I expect someone to write sooner or later). -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Thu Jan 27 02:56: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 CAA28938 for ; Thu, 27 Jan 2005 02:56: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 j0R7fgZL043788; Wed, 26 Jan 2005 23:41: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 j0R7fghI043787; Wed, 26 Jan 2005 23:41:42 -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 j0R7ff9U043776 for ; Wed, 26 Jan 2005 23:41:41 -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 j0R7ffdt025343 for ; Thu, 27 Jan 2005 00:41: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 <0IAY00A1FTDGHV@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 27 Jan 2005 00:41:41 -0700 (MST) Received: from [192.168.1.17] ([216.113.201.159]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAY005N2TDGUN@mail.sun.net> for atom-syntax@imc.org; Thu, 27 Jan 2005 00:41:40 -0700 (MST) Date: Wed, 26 Jan 2005 23:41:39 -0800 From: Tim Bray Subject: Re: Difference of TEXT and XHTML? In-reply-to: <46BD6BB9-7034-11D9-B1FA-003065B8CF0E@iki.fi> To: Henri Sivonen Cc: Atom Syntax , Sam Ruby 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: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> <41F8549C.3000904@intertwingly.net> <46BD6BB9-7034-11D9-B1FA-003065B8CF0E@iki.fi> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 26, 2005, at 11:23 PM, Henri Sivonen wrote: > But type='TEXT' is only a degenerate case of type='XHTML' > (type='XHTML' with only text content). What value does type='TEXT' add > to the format except the ability of feedvalidator.org to detect cases > where there are element children although the author claims there are > not, which suggests an authoring error? Does type='TEXT' intentionally > exist only to add this feedvalidator.org value? OK, you've advanced this argument several times now. If you want to change the Atom format to remove type="TEXT", write a Pace (it'll be short & easy) and see if you can build consensus. I have to warn you that the process by which we got to consensus on the current setup was long, arduous, and involved a huge volume of email, and you may get -1's based on people just not wanting to revisit this space. -Tim From owner-atom-syntax@mail.imc.org Thu Jan 27 02:56: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 CAA28963 for ; Thu, 27 Jan 2005 02:56: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 j0R7gq45044262; Wed, 26 Jan 2005 23:42: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 j0R7gqCO044261; Wed, 26 Jan 2005 23:42: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 j0R7gm3G044035 for ; Wed, 26 Jan 2005 23:42: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); Thu, 27 Jan 2005 20:42:55 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 27 Jan 2005 18:42:11 +1100 Subject: Re: Difference of TEXT and XHTML? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1743E1A5-7033-11D9-B1FA-003065B8CF0E@iki.fi> 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 27/1/05 6:14 PM, "Henri Sivonen" wrote: >> try instead this example "I <3 Huckabees"... > > That makes no difference, either. > > I <3 Huckabees > > Only type='HTML' is different. > et al has been dropped from XHTML 1.1, 2.0 and the Strict DTD's (which is recommended to use over the Transitional ones). > Because having control over presentation is the main reason to format > content as HTML. Uhm. Okay. -- 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 Thu Jan 27 03: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 DAA00184 for <atompub-archive@lists.ietf.org>; Thu, 27 Jan 2005 03:11: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 j0R7lvD4046196; Wed, 26 Jan 2005 23: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 j0R7lvc6046195; Wed, 26 Jan 2005 23:47:57 -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 j0R7ltMJ046168 for <atom-syntax@imc.org>; Wed, 26 Jan 2005 23:47:56 -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, 27 Jan 2005 20:48:34 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 27 Jan 2005 18:47:50 +1100 Subject: Re: Difference of TEXT and XHTML? From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE1EE7D6.449FA%eric.scheid@ironclad.net.au> In-Reply-To: <46BD6BB9-7034-11D9-B1FA-003065B8CF0E@iki.fi> 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 27/1/05 6:23 PM, "Henri Sivonen" <hsivonen@iki.fi> wrote: > But type='TEXT' is only a degenerate case of type='XHTML' (type='XHTML' > with only text content). What value does type='TEXT' add to the format > except the ability of feedvalidator.org to detect cases where there are > element children although the author claims there are not, which > suggests an authoring error? Does type='TEXT' intentionally exist only > to add this feedvalidator.org value? maybe it exists so I can write a title which looks like this "I hate the <blink> tag" which is the plain text rendition, or if I wanted to code it in html/xhtml it would be "I hate the <blink> tag" and then applying XML escaping ... would be the following? ... <title type='TEXT >I hate the <blink< tag I hate the &lt;blink&< tag e. From owner-atom-syntax@mail.imc.org Thu Jan 27 03:48: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 DAA03151 for ; Thu, 27 Jan 2005 03:48: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 j0R8RGpm078277; Thu, 27 Jan 2005 00:27: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 j0R8RGiX078276; Thu, 27 Jan 2005 00:27:16 -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 j0R8RFvf078119 for ; Thu, 27 Jan 2005 00:27:16 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-12.adsl-net.finnetcom.net ([217.140.228.12]:52601 "EHLO [217.140.228.12]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228826AbVA0I07 (ORCPT ); Thu, 27 Jan 2005 10:26:59 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <34D24F9A-703D-11D9-B1FA-003065B8CF0E@iki.fi> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henri Sivonen Subject: Re: PaceEnclosuresAndPix status Date: Thu, 27 Jan 2005 10:26:56 +0200 To: Eric Scheid X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 27, 2005, at 07:40, Eric Scheid wrote: > agreed, a single term @rel value is preferred. I'd prefer an element, because the nature of the favicon reference is not that a user would want to manually follow the link. That is: or -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Thu Jan 27 04:30: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 EAA06574 for ; Thu, 27 Jan 2005 04:30: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 j0R9JsKD032233; Thu, 27 Jan 2005 01:19: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 j0R9Jsft032232; Thu, 27 Jan 2005 01:19:54 -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 j0R9Jrin032224 for ; Thu, 27 Jan 2005 01:19:53 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 14266 invoked by uid 17064); 27 Jan 2005 09:19:52 -0000 Received: from unknown (HELO [192.168.0.5]) ([83.112.104.25]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 27 Jan 2005 09:19:52 -0000 In-Reply-To: <41F8545B.8070801@intertwingly.net> References: <1f2ed5cd05012602474fc907a1@mail.gmail.com> <41F7A320.9020906@intertwingly.net> <8631b39ab59dd87f9ad947318c513654@bblfish.net> <41F8545B.8070801@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <775f816d07b9c2f53153930d59fb194d@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax , Danny Ayers From: Henry Story Subject: Re: PaceAttributesNamespace is *not* about syntax! Date: Thu, 27 Jan 2005 10:19:47 +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 Thanks for the reply, Sam. I think the misunderstanding has mostly to do with the fact that we have similar but slightly different aims. We should try to clearly establish our respective aims and find the points we have in common, so that we can agree to solve the points we have in common quickly and easily. On 27 Jan 2005, at 03:39, Sam Ruby wrote: > Henry Story wrote: >> On 26 Jan 2005, at 15:03, Sam Ruby wrote: >>> [...] >>> But, now lets examine the statement proposed in >>> PaceAttributeNamespace. It essentially alerts producers of >>> something that that they need to be aware of. Now a quesion: what >>> do they need do different with the knowledge that the RDF mapping >>> does this? >>> >>> I would assert the answer to this question is nothing. Meaning that >>> this particular statement is not needed. Again, no issue with the >>> mapping. No issue with describing the mapping alongside with the >>> actual mapping. >> I think your assertion is wrong. If they are consuming or producing >> extended Atom [1] >> they will know exactly what these extensions are referring to. It >> won't >> affect in the least consumers of simple, non extended Atom, but it >> will greatly >> help consumers and producers of extended atom. >> Now if you don't care about making their lives easier, then you have >> nothing >> to worry about in this pace. If you do, like I and many others, then >> this will >> be very helpful. > > It seems to me that you are both misunderstanding and > mischaracterizing what I am saying. Furthermore, in other emails, I > sense a confusion between RDF (which is a model) and RDF/XML (which is > a syntax). No worry. I think we all know the difference there, but the language does lend itself to confusion. > I am in favor of AtomAsRDF (as a way to model this data). I am opposed > to AtomAsRDFXML (as a syntax for expressing this model). Ok. I am in favor of AtomAsRDF(Model) too. But I am trying to go a little further to AtomAsRDFXML (as you put it) because - The spec can very nearly already be interpreted that way - defining another mapping from xml to RDF, though possible, is a lot of work, and we just don't have the time - it will allow for the easiest way to explain extensibility of Atom So though I think (and I have recently myself tried out some ideas on this subject) there may be some general mapping rule from xml to rdf that are much closer to the general users intuitions about xml, I think that when the xml is written as atom currently (nearly) is, we have something that does map to a graph and that will map to the same graph than any more intuitive mapping than rdf/xml would. > If anybody is up to the task, I am for inclusion of prose into the > standard describing how one is to interpret Atom feeds as RDF. Any > such > mechanism that accomplishes this will, by necessity, need to specify > what namespace is used in the URIs used to define relationships. Well I liked your idea of adding a special section to the spec on how to interpret atom as rdf/xml, perhaps as part of the extensibility section. My feeling is that would be best if it explains how atom can be seen to be rdf/xml, because then explaining extensibility will be very easy: "any atom document with foreign name spaced attributes or elements must also be an rdf/xml document when so interpreted" And we then leave the complexity of that statement to the other specs out there. > PaceAttributeNamespace does not do that. All it says is is that a > given > namespace may be used. For what purpose such a statement is made is > entirely unclear. > > By contrast, a precise statement to the effect of how RDF aware tools > MUST interpret Atom feeds if they are to interoperate is both clear and > useful. Ok. Well I think we are really thinking very similar thoughts here. I would just add that we should try to see if the RDF/XML interpretation of Atom works out, because that will vastly reduce the amount of work we need to do in explaining the interpretation. ("interpretation" is an excellent word!) Henry Story > - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Jan 27 06:28: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 GAA18070 for ; Thu, 27 Jan 2005 06: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 j0RBDGvF073050; Thu, 27 Jan 2005 03:13: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 j0RBDGrW073049; Thu, 27 Jan 2005 03:13: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 j0RBDDUR072878 for ; Thu, 27 Jan 2005 03:13: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, 28 Jan 2005 00:13:22 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 27 Jan 2005 22:12:41 +1100 Subject: Re: PaceEnclosuresAndPix status From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <34D24F9A-703D-11D9-B1FA-003065B8CF0E@iki.fi> 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 27/1/05 7:26 PM, "Henri Sivonen" wrote: > I'd prefer an element, because the nature of the favicon reference is > not that a user would want to manually follow the link. That is: > > or I've drafted a Pace for this... http://www.intertwingly.net/wiki/pie/PaceIconAndImage This competes with parts of PaceEnclosuresAndPix, and so have also written PaceLinkEnclosure which simply strips out the Pix part. http://www.intertwingly.net/wiki/pie/PaceLinkEnclosure e. From owner-atom-syntax@mail.imc.org Thu Jan 27 07:39: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 HAA26458 for ; Thu, 27 Jan 2005 07:39: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 j0RCMgsE095605; Thu, 27 Jan 2005 04:22: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 j0RCMfFS095604; Thu, 27 Jan 2005 04:22:41 -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 j0RCMdh7095496 for ; Thu, 27 Jan 2005 04:22:40 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-12.adsl-net.finnetcom.net ([217.140.228.12]:52693 "EHLO [217.140.228.12]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228796AbVA0MWZ (ORCPT ); Thu, 27 Jan 2005 14:22:25 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <187D35D6-705E-11D9-B1FA-003065B8CF0E@iki.fi> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henri Sivonen Subject: Re: Difference of TEXT and XHTML? Date: Thu, 27 Jan 2005 14:22:22 +0200 To: Eric Scheid X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 27, 2005, at 09:42, Eric Scheid wrote: > > On 27/1/05 6:14 PM, "Henri Sivonen" wrote: > >>> try instead this example "I <3 Huckabees"... >> >> That makes no difference, either. >> >> I <3 Huckabees >> >> Only type='HTML' is different. >> I &lt;3 Huckabees > is that right for XHTML? Yes. > after XML decoding, the string data would be "I <3 Huckabees", which if > directly embedded into an XHTML
would be broken... > > > >
I <3 Huckabees
> > > what am I missing? You try to concatenate the parsed text node content string to a skeleton source string instead of moving the parsed text node to skeleton tree. When <head/><body><div>I <3 Huckabees</div></body></html> -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Thu Jan 27 07:59: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 HAA28316 for <atompub-archive@lists.ietf.org>; Thu, 27 Jan 2005 07:59: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 j0RCkBvT003515; Thu, 27 Jan 2005 04:46: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 j0RCkBml003514; Thu, 27 Jan 2005 04:46: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 j0RCkAeq003490 for <atom-syntax@imc.org>; Thu, 27 Jan 2005 04:46:10 -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, 28 Jan 2005 01:46:50 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 27 Jan 2005 23:46:08 +1100 Subject: Re: Difference of TEXT and XHTML? From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE1F2DC0.44A99%eric.scheid@ironclad.net.au> In-Reply-To: <187D35D6-705E-11D9-B1FA-003065B8CF0E@iki.fi> 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 27/1/05 11:22 PM, "Henri Sivonen" <hsivonen@iki.fi> wrote: > When <title type='XHTML>I <3 Huckabees is parsed, you get a > 'title' element node with a text node child whose content is "I <3 > Huckabees". To form an XHTML document, you don't concatenate that > string to some source markup, but you move the text node to a tree like > this (assume XHTML namespace): > html > head > body > div > #text: "I <3 Huckabees" > > If this tree is now serialized, we get >
I <3 > Huckabees
ahhhm ... ok, sounds reasonable. however, the spec says: The content SHOULD be XHTML text and markup that could validly appear directly within an xhtml:div element. which could lead others to make the same mistake I must have made. e. From owner-atom-syntax@mail.imc.org Thu Jan 27 08:35: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 IAA03136 for ; Thu, 27 Jan 2005 08:35: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 j0RDLTrn016236; Thu, 27 Jan 2005 05:21: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 j0RDLT0v016235; Thu, 27 Jan 2005 05:21:29 -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 j0RDLSYH016190 for ; Thu, 27 Jan 2005 05:21:28 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-12.adsl-net.finnetcom.net ([217.140.228.12]:52786 "EHLO [217.140.228.12]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228901AbVA0NVX (ORCPT ); Thu, 27 Jan 2005 15:21:23 +0200 In-Reply-To: References: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> <41F8549C.3000904@intertwingly.net> <46BD6BB9-7034-11D9-B1FA-003065B8CF0E@iki.fi> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <54DCCFA2-7066-11D9-B1FA-003065B8CF0E@iki.fi> Content-Transfer-Encoding: 7bit Cc: Atom Syntax , Sam Ruby From: Henri Sivonen Subject: Re: Difference of TEXT and XHTML? Date: Thu, 27 Jan 2005 15:21:19 +0200 To: Tim Bray X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 27, 2005, at 09:41, Tim Bray wrote: > OK, you've advanced this argument several times now. If you want to > change the Atom format to remove type="TEXT", write a Pace (it'll be > short & easy) and see if you can build consensus. http://www.intertwingly.net/wiki/pie/PaceTypeTextRedundant > I have to warn you that the process by which we got to consensus on > the current setup was long, arduous, and involved a huge volume of > email, and you may get -1's based on people just not wanting to > revisit this space. Sure, the current version is better than the mode/type stuff. -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Thu Jan 27 08:45: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 IAA04810 for ; Thu, 27 Jan 2005 08:45: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 j0RDYmqU017879; Thu, 27 Jan 2005 05:34: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 j0RDYlLW017878; Thu, 27 Jan 2005 05:34:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [69.20.61.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0RDYkGU017871 for ; Thu, 27 Jan 2005 05:34:47 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [10.254.1.50] (216-31-236-219.cust.telepacific.net [216.31.236.219]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.10) with ESMTP id j0RDYZe3010213; Thu, 27 Jan 2005 08:34:39 -0500 Message-ID: <41F8EDEC.6050705@intertwingly.net> Date: Thu, 27 Jan 2005 08:34: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: Henri Sivonen CC: Atom Syntax Subject: Re: Difference of TEXT and XHTML? References: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> <41F8549C.3000904@intertwingly.net> <46BD6BB9-7034-11D9-B1FA-003065B8CF0E@iki.fi> <54DCCFA2-7066-11D9-B1FA-003065B8CF0E@iki.fi> In-Reply-To: <54DCCFA2-7066-11D9-B1FA-003065B8CF0E@iki.fi> 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 Henri Sivonen wrote: > On Jan 27, 2005, at 09:41, Tim Bray wrote: > >> OK, you've advanced this argument several times now. If you want to >> change the Atom format to remove type="TEXT", write a Pace (it'll be >> short & easy) and see if you can build consensus. > > http://www.intertwingly.net/wiki/pie/PaceTypeTextRedundant There are cases where explicit is better than implicit. The default for title should be TEXT - i.e., no markup. Those that wish to add markup should be required to be explicit about it. Particularly, as this has proven to be a very error prone process. Allowing the declaration of markup to be implicit (i.e., having a default for type) will lead to continued confusion and errors. I am -1 on this Pace. Making type required on all textual elements would address my concern, but my preference is to leave the spec as it is. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Jan 27 09:09: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 JAA07678 for ; Thu, 27 Jan 2005 09:09: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 j0RDtr73019347; Thu, 27 Jan 2005 05:55: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 j0RDtraa019346; Thu, 27 Jan 2005 05:55: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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0RDtqvB019340 for ; Thu, 27 Jan 2005 05:55:53 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so226652rnz for ; Thu, 27 Jan 2005 05:55: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=Sp2qL++dKa8YImsKZb8eIUTA+oFEN4TWZD7DWMRz3qam4rzf2typw2ZuHJ0rsriyJnD6yLyMugBBtOGYTmTDE/M0s7r5daeloqUWjp9iJoK8B+xvFRj+59iDsfFqieyev8GavlyemDRLgq9Lj1WI1+kZuBBWV2xGzfuqYAICqL4= Received: by 10.38.206.28 with SMTP id d28mr71364rng; Thu, 27 Jan 2005 05:55:52 -0800 (PST) Received: by 10.38.179.71 with HTTP; Thu, 27 Jan 2005 05:55:52 -0800 (PST) Message-ID: <1f2ed5cd0501270555412db7f6@mail.gmail.com> Date: Thu, 27 Jan 2005 14:55:52 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Sam Ruby Subject: Re: PaceAttributesNamespace is *not* about syntax! Cc: Henry Story , atom-syntax@imc.org In-Reply-To: <41F8545B.8070801@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd05012602474fc907a1@mail.gmail.com> <41F7A320.9020906@intertwingly.net> <8631b39ab59dd87f9ad947318c513654@bblfish.net> <41F8545B.8070801@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 26 Jan 2005 21:39:23 -0500, Sam Ruby wrote: > PaceAttributeNamespace does not do that. All it says is is that a given > namespace may be used. For what purpose such a statement is made is > entirely unclear. Ok, maybe a little more explanation is needed in the Pace. The purpose is to provide global names to the relations expressed by the attributes. "Global naming leads to global network effects." http://www.w3.org/TR/2004/REC-webarch-20041215/#identification Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Jan 27 09:37: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 JAA10564 for ; Thu, 27 Jan 2005 09:37: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 j0RESIZ1021656; Thu, 27 Jan 2005 06:28: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 j0RESIPE021655; Thu, 27 Jan 2005 06:28:18 -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 j0RESHo8021642 for ; Thu, 27 Jan 2005 06:28:17 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 15233 messnum 3867974 invoked from network[213.94.211.166/mail2.newbay.com]); 27 Jan 2005 14:28:11 -0000 Received: from mail2.newbay.com (HELO ?192.168.213.135?) (213.94.211.166) by mail08.svc.cra.dublin.eircom.net (qp 15233) with SMTP; 27 Jan 2005 14:28:11 -0000 Message-ID: <41F8FA79.4010906@dehora.net> Date: Thu, 27 Jan 2005 14:28:09 +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: Henry Story CC: Graham , Atom Syntax Subject: Re: PaceAttributesNamespace is *not* about syntax! References: <1f2ed5cd05012602474fc907a1@mail.gmail.com> <41F7A320.9020906@intertwingly.net> <8631b39ab59dd87f9ad947318c513654@bblfish.net> <3a0a09cffb909f5b93a3f6762f27f9e8@bblfish.net> In-Reply-To: <3a0a09cffb909f5b93a3f6762f27f9e8@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: > > Graham the Robot [1], when real people come and ask me something I'll > talk to them. Rudeness objection. I'm seeing genuine questions; fobbing them off (as above) is not helping your case. cheers Bill From owner-atom-syntax@mail.imc.org Thu Jan 27 09:40: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 JAA11143 for ; Thu, 27 Jan 2005 09:40: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 j0REPjNT021466; Thu, 27 Jan 2005 06:25: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 j0REPjqG021465; Thu, 27 Jan 2005 06:25:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [69.20.61.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0REPik5021458 for ; Thu, 27 Jan 2005 06:25:44 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [10.254.1.50] (216-31-236-219.cust.telepacific.net [216.31.236.219]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.10) with ESMTP id j0REPfnY017823; Thu, 27 Jan 2005 09:25:41 -0500 Message-ID: <41F8F9E6.4040808@intertwingly.net> Date: Thu, 27 Jan 2005 09:25: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: Danny Ayers CC: Henry Story , atom-syntax@imc.org Subject: Re: PaceAttributesNamespace is *not* about syntax! References: <1f2ed5cd05012602474fc907a1@mail.gmail.com> <41F7A320.9020906@intertwingly.net> <8631b39ab59dd87f9ad947318c513654@bblfish.net> <41F8545B.8070801@intertwingly.net> <1f2ed5cd0501270555412db7f6@mail.gmail.com> In-Reply-To: <1f2ed5cd0501270555412db7f6@mail.gmail.com> 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 Danny Ayers wrote: > On Wed, 26 Jan 2005 21:39:23 -0500, Sam Ruby wrote: > >>PaceAttributeNamespace does not do that. All it says is is that a given >>namespace may be used. For what purpose such a statement is made is >>entirely unclear. > > Ok, maybe a little more explanation is needed in the Pace. The purpose > is to provide global names to the relations expressed by the > attributes. > > "Global naming leads to global network effects." > http://www.w3.org/TR/2004/REC-webarch-20041215/#identification So... define the cases where it MUST be used ... and how ... in order to achieve interoperability. If the desire is to "provide global names to the relations expressed by the attributes", then it would make sense to describe what namespace MUST be used for such relationships. Perhaps in the portion of the document which describes how one is to infer such relations from the raw xml attributes. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Jan 27 09:57: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 JAA12671 for ; Thu, 27 Jan 2005 09:57: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 j0RElLhV023152; Thu, 27 Jan 2005 06:47: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 j0RElLB6023151; Thu, 27 Jan 2005 06:47: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 j0RElK3e023102 for ; Thu, 27 Jan 2005 06:47:20 -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, 28 Jan 2005 03:47:30 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 28 Jan 2005 01:46:48 +1100 Subject: PaceIconAndImage, and PaceLinkEnclosure 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 resending with more appropriate subject line, just in case these two new paces got lost in the thread... > I'd prefer an element, because the nature of the favicon reference is > not that a user would want to manually follow the link. That is: > > or I've drafted a Pace for this... http://www.intertwingly.net/wiki/pie/PaceIconAndImage This competes with parts of PaceEnclosuresAndPix, and so have also written PaceLinkEnclosure which simply strips out the Pix part. http://www.intertwingly.net/wiki/pie/PaceLinkEnclosure e. From owner-atom-syntax@mail.imc.org Thu Jan 27 10:02: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 KAA13183 for ; Thu, 27 Jan 2005 10:02: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 j0REpl34023461; Thu, 27 Jan 2005 06:51: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 j0REpl1M023460; Thu, 27 Jan 2005 06:51: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 j0REpk8l023429 for ; Thu, 27 Jan 2005 06:51: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 j0REmkhT006087; Thu, 27 Jan 2005 14:48:51 GMT In-Reply-To: <41F8EDEC.6050705@intertwingly.net> References: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> <41F8549C.3000904@intertwingly.net> <46BD6BB9-7034-11D9-B1FA-003065B8CF0E@iki.fi> <54DCCFA2-7066-11D9-B1FA-003065B8CF0E@iki.fi> <41F8EDEC.6050705@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-20--318894347; protocol="application/pkcs7-signature" Message-Id: <8AFF49E7-7072-11D9-9153-000A95DC3D90@mac.com> Cc: Atom Syntax , Henri Sivonen From: Graham Subject: Re: Difference of TEXT and XHTML? Date: Thu, 27 Jan 2005 14:48:44 +0000 To: Sam Ruby X-Mailer: Apple Mail (2.619) 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--318894347 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 27 Jan 2005, at 1:34 pm, Sam Ruby wrote: >> http://www.intertwingly.net/wiki/pie/PaceTypeTextRedundant > > There are cases where explicit is better than implicit. Yes. It's more a psychological rather than a technical difference, but I think it's important (it's like the difference between ASCII and UTF-8). -1 on the pace. Graham (PS Are line breaks in Text mode honored?) --Apple-Mail-20--318894347 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 9w0BCQUxDxcNMDUwMTI3MTQ0ODQ0WjAjBgkqhkiG9w0BCQQxFgQUk58HlO8XemUmW3D+M0+1kSch Dw4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAO4OVIozCG/cFsN53fQceZfe9 NErBIlvpKuO8jyx4hUormFAx7RTWvMDILCDPMFTFGc5nA7zPGL8W9Ie/ZUG+E/bkKuFIbVm0YFK6 EZV8nUcZl1THH6xp7Z12ZVnfxB0aJPb2PIBu3bsEnGTtVmYiPp02Vttb/KyohKPx+edju8yOLk6V YuLr12UG6MbITDbcidJF+lXs7w3egkSYdlrxvoh61KIUT9ViOaCJ2FG+uXl+Rym1EEBGGI6eDpXO pxfKaUEezQhkwEZumVgUl31z4Jx6n8/q10RwuLSgeRgMgcWugjzlTVLq0Enyn8OY8GyX6scKpTNJ deDr3cdlydgd0gAAAAAAAA== --Apple-Mail-20--318894347-- From owner-atom-syntax@mail.imc.org Thu Jan 27 10:08: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 KAA14394 for ; Thu, 27 Jan 2005 10:08: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 j0REpsMA023478; Thu, 27 Jan 2005 06:51: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 j0REpsL7023477; Thu, 27 Jan 2005 06:51:54 -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 j0REpseq023468 for ; Thu, 27 Jan 2005 06:51:54 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so230877rnz for ; Thu, 27 Jan 2005 06:51:50 -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=Qco843sYyLjoEy5kelW/Y2enFmqUJsYBoStVU9zoEEccMdwhr67r11ZmF/h7yWGDnW25Pb5kxXzdiH8ZBctSw3jdOyerkwO5duAno+zeMd90M+8Lh/8Ovo7S31fZJTW/UpZ6fCUOEaSwOVgAkrZ2rktl0gA9Q9OPKjZv0qmEEv0= Received: by 10.38.179.46 with SMTP id b46mr95090rnf; Thu, 27 Jan 2005 06:51:50 -0800 (PST) Received: by 10.38.179.71 with HTTP; Thu, 27 Jan 2005 06:51:50 -0800 (PST) Message-ID: <1f2ed5cd050127065121d3bd15@mail.gmail.com> Date: Thu, 27 Jan 2005 15:51:50 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Henry Story Subject: Re: PaceExtensionConstruct status Cc: danbri@w3.org, atom-syntax@imc.org, David Powell In-Reply-To: <1f8df8f84b530278821f37c506c25391@bblfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <893856C5-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f50501241659610acb49@mail.gmail.com> <1742148530.20050125021028@djpowell.net> <1f2ed5cd05012611163deb9672@mail.gmail.com> <1f8df8f84b530278821f37c506c25391@bblfish.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 26 Jan 2005 22:13:34 +0100, Henry Story wrote: > Yes. That is indeed tricky, and probably a little beyond my present > skill set. I thought someone said on this list recently that it was > possible > perhaps using xmlschema and treating the content as a special literal. I > just can't find the reference anymore. Yep, my first impression was that it should be possible to define what goes in content using an XML Schema datatype, e.g. yodel-ay-ey-oo But now I don't think this will be quite as straightforward as I'd hoped - "TEXT" and "XHTML" should be straightforward to define in XSD (either by reference to a schema for XHTML, or simply dumbed down to noChildren/anyXML). But "HTML" is trickier, because it is intended to included escaped markup destined for subsequent HTML processors. In the XML document, I believe this will appear just like "TEXT". There's no obvious way of including the information that it's HTML. Because of this the neatest machine-readable expression of the type I can think of would be through an n-ary relation: yodel-ay-ey-oo TEXT It's moving still further away from Atom syntax, but I suspect this would be more useful than forcing the model to follow the syntax. A hybrid in between would probably be possible, but more confusing for little benefit. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Jan 27 10:40: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 KAA19912 for ; Thu, 27 Jan 2005 10:40: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 j0RFE1r4025539; Thu, 27 Jan 2005 07:14: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 j0RFE1cn025538; Thu, 27 Jan 2005 07:14: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.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0RFE0te025532 for ; Thu, 27 Jan 2005 07:14:01 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so232660rnz for ; Thu, 27 Jan 2005 07:14: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:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Pp2UDJyN5/rTD7k0XD2P14tHgdKPbKB7SHBkGVOC0zWlIAXSgH36JLe0zKDwLFM75K9Etn9ky5oOX+szDXd0euN5R/QGDuFMk1mDbLzJ7paIzB3jnG9IUDwFnh7HuVxiHpNgOH/a8Q/KDakyD4lhmbPq366ycASqHmWd3cIOa2g= Received: by 10.38.26.40 with SMTP id 40mr529483rnz; Thu, 27 Jan 2005 07:14:00 -0800 (PST) Received: by 10.38.179.71 with HTTP; Thu, 27 Jan 2005 07:14:00 -0800 (PST) Message-ID: <1f2ed5cd050127071410abcb9f@mail.gmail.com> Date: Thu, 27 Jan 2005 16:14:00 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Graham Subject: Re: Difference of TEXT and XHTML? Cc: Sam Ruby , Atom Syntax , Henri Sivonen In-Reply-To: <8AFF49E7-7072-11D9-9153-000A95DC3D90@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> <41F8549C.3000904@intertwingly.net> <46BD6BB9-7034-11D9-B1FA-003065B8CF0E@iki.fi> <54DCCFA2-7066-11D9-B1FA-003065B8CF0E@iki.fi> <41F8EDEC.6050705@intertwingly.net> <8AFF49E7-7072-11D9-9153-000A95DC3D90@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I only noticed this thread after looking at the same material through RDF-tinted spectacles. A question for the schema mavens: is there *any* clear way of describing the difference between the three content types (TEXT/HTML/XHTML) in a machine readable fashion? In the Rosy-tinted Description Framework, if the type could be fully expressed using XML Schema datatypes, the Atom content element could map nicely onto a XSD-datatyped literal. Problem is I couldn't see any obvious way of distinguishing HTML from TEXT, as the former would be escaped anyway. So in effect for RDF I think the content would have to appear as a literal, with the type as a kind of annotation, the easiest RDF/XML version being something like: yodel-ay-ey-oo TEXT Cheers, Danny. On Thu, 27 Jan 2005 14:48:44 +0000, Graham wrote: > On 27 Jan 2005, at 1:34 pm, Sam Ruby wrote: > > >> http://www.intertwingly.net/wiki/pie/PaceTypeTextRedundant > > > > There are cases where explicit is better than implicit. > > Yes. It's more a psychological rather than a technical difference, but > I think it's important (it's like the difference between ASCII and > UTF-8). > > -1 on the pace. > > Graham > > (PS Are line breaks in Text mode honored?) > > -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Jan 27 10:56: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 KAA21611 for ; Thu, 27 Jan 2005 10:56: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 j0RFcFe5027590; Thu, 27 Jan 2005 07:38: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 j0RFcFlt027589; Thu, 27 Jan 2005 07:38:15 -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 j0RFcFLc027580 for ; Thu, 27 Jan 2005 07:38:15 -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 <2005012715380901200fv109e>; Thu, 27 Jan 2005 15:38:09 +0000 Date: Thu, 27 Jan 2005 08:38:07 -0700 Subject: Re: PaceEnclosuresAndPix status 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: <715FED84-7079-11D9-9325-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, January 26, 2005, at 10:40 PM, Eric Scheid wrote: > so, "icon" ... or "favicon". > > I prefer the latter. I prefer the former. "favicon" => "favorites icon". I think "favorites" is a bad name for bookmarks--a person's reason for bookmarking something (or in the case of Atom, subscribing to a feed) may not have anything to do with how much they like it. And besides, the icon is displayed (in some browsers at least) when you're viewing the page, not just when it's bookmarked. I'd rather not propagate the use of the term. Let's just call it what we know it is--an icon. From owner-atom-syntax@mail.imc.org Thu Jan 27 11:04: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 LAA22360 for ; Thu, 27 Jan 2005 11:04: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 j0RFotPi028813; Thu, 27 Jan 2005 07:50: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 j0RFotNw028812; Thu, 27 Jan 2005 07:50:55 -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 j0RForSG028805 for ; Thu, 27 Jan 2005 07:50:54 -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 j0RForVu017222 for ; Thu, 27 Jan 2005 08:50:53 -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 <0IAZ00A17G0TTN@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 27 Jan 2005 08:50:53 -0700 (MST) Received: from [192.168.1.17] ([216.113.201.159]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAZ00725G0SOP@mail.sun.net> for atom-syntax@imc.org; Thu, 27 Jan 2005 08:50:53 -0700 (MST) Date: Thu, 27 Jan 2005 07:50:51 -0800 From: Tim Bray Subject: Re: Difference of TEXT and XHTML? In-reply-to: To: Eric Scheid Cc: Atom Syntax Message-id: <38356220-707B-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: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 27, 2005, at 4:46 AM, Eric Scheid wrote: > however, the spec says: > > The content SHOULD be XHTML text and markup that could > validly appear directly within an xhtml:div element. > > which could lead others to make the same mistake I must have made. The easiest way to solve this, I think, is with examples. -Tim From owner-atom-syntax@mail.imc.org Thu Jan 27 11:05: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 LAA22541 for ; Thu, 27 Jan 2005 11:05: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 j0RFnZ5t028712; Thu, 27 Jan 2005 07:49: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 j0RFnZPv028711; Thu, 27 Jan 2005 07:49:35 -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 j0RFnZlt028705 for ; Thu, 27 Jan 2005 07:49:35 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 53676 invoked by uid 17064); 27 Jan 2005 15:49:35 -0000 Received: from unknown (HELO [192.168.0.5]) ([83.112.101.161]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 27 Jan 2005 15:49:35 -0000 In-Reply-To: <41F8FA79.4010906@dehora.net> References: <1f2ed5cd05012602474fc907a1@mail.gmail.com> <41F7A320.9020906@intertwingly.net> <8631b39ab59dd87f9ad947318c513654@bblfish.net> <3a0a09cffb909f5b93a3f6762f27f9e8@bblfish.net> <41F8FA79.4010906@dehora.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <4306003c75fefe938dc569e28b7f88d0@bblfish.net> Cc: Graham , Atom Syntax From: Henry Story Subject: Re: PaceAttributesNamespace is *not* about syntax! Date: Thu, 27 Jan 2005 16:49:29 +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 j0RFnZlt028706 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 27 Jan 2005, at 15:28, Bill de hÓra wrote: > Rudeness objection. One reaps what one sows. [1] > I'm seeing genuine questions Since you are asking, I'll answer them. > On 26 Jan 2005, at 4:37 pm, Henry Story wrote: >> I think your assertion is wrong. If they are consuming or producing >> extended Atom [1] >> they will know exactly what these extensions are referring to. It >> won't >> affect in the least consumers of simple, non extended Atom, but it >> will greatly >> help consumers and producers of extended atom. > > What will? To what does "these extensions" refer? How will "it" help > who? Consider the problem of creating extensions to Atom. You are adding a new vocabulary to the current atom vocabulary, so you will have non atom name spaced elements or attributes in your extended atom document. Atom Robots run amok ... We are all agreed about what the above document means, stripped of the my:illustration tag. Parsers that only wish to concern themselves with those striped documents will have no trouble. The spec clearly specifies what is what. The problem is to clearly specify how extended atom documents like the one above are to be written consistently, so that they can be interpreted correctly, the way the writer of the document intended them to be. > To what does "these extensions" refer? These extensions refer to attributes such as my:href in the example above. > How will "it" help who? The problem is that attributes in atom are not namespaced. If they were then it would be easy to interpret the above document as an rdf document. An rdf document has very clearly specified semantics. Having these clearly specified semantics is very helpful to extension writers and consumers. The details of how it will help are much more difficult to explain in a short e-mail such as this. A hint is contained in the word "onotology". This has to do with Objects. And there is a very strong relationship between OO programming and what is being proposed here. The benefits of OO programming are the same benefits we stand to gain here: it makes it much easier to create elements and specify how they can be combined. But it would perhaps be best to work through an example to help show how this works. Does this help? Henry Story [1] http://www.imc.org/atom-syntax/mail-archive/msg12038.html From owner-atom-syntax@mail.imc.org Thu Jan 27 11:29: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 LAA26116 for ; Thu, 27 Jan 2005 11:29: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 j0RG8hIB030040; Thu, 27 Jan 2005 08:08: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 j0RG8hpf030039; Thu, 27 Jan 2005 08:08:43 -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 j0RG8gvS030029 for ; Thu, 27 Jan 2005 08:08:42 -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 <2005012716083601100cii80e>; Thu, 27 Jan 2005 16:08:36 +0000 Date: Thu, 27 Jan 2005 09:08:34 -0700 Subject: 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: <34D24F9A-703D-11D9-B1FA-003065B8CF0E@iki.fi> 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, January 27, 2005, at 01:26 AM, Henri Sivonen wrote: > I'd prefer an element, because the nature of the favicon reference is > not that a user would want to manually follow the link. That is: > > or > While I agree with this sentiment, the working group has rejected attempts to add language to the spec to limit the use of , so I assume we do not have consensus on the desire to limit it's usage. So that's not necessarily a very strong argument for creating new elements (not that there aren't other arguments for it). Of the two options you listed, I'd prefer @src to @href...for reasons related to my agreement with the sentiment about the use of here. "src" is much more description of how the attribute's value is going to be used. Which brings me to PaceIconAndImage--the pace itself makes forbids putting one of the attributes of Link Constructs in the elements (@rel). Another of them (@href) is not accurately descriptive of what it would be used for. Another of them (@title) doesn't seem very useful for icon (unless for accessibility--do people more involved in accessibility issues think that's needed--that it's going to be used to say anything more than "xyz.com's icon"?) Is it really appropriate to call this a Link Construct? Also, why limit this to feed/head, and not entry? So that Atom feeds will be easily convertible to RSS 2.0? Certainly there are ways to add images to entries in RSS 2.0, though not icons (as far as I'm aware), but I don't think that's a big deal. Because link/@rel="enclosure|attachment" can be used for images at the entry level? Then why not do the same at the feed level? Because we don't have prior art for needing it at the entry level? True for icons, less true for images, but still probably the strongest argument. But I would still argue for allowing them in entries. From owner-atom-syntax@mail.imc.org Thu Jan 27 11:59: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 LAA29267 for ; Thu, 27 Jan 2005 11:58: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 j0RGj8nH032791; Thu, 27 Jan 2005 08:45: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 j0RGj8hv032790; Thu, 27 Jan 2005 08:45: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 j0RGj7Kw032782 for ; Thu, 27 Jan 2005 08:45:07 -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 1CuClR-0004N7-Na; Thu, 27 Jan 2005 16:45:01 +0000 Message-ID: <41F91A8D.4080700@franklinmint.fm> Date: Thu, 27 Jan 2005 11:45:01 -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: Sam Ruby , Atom Syntax , Henri Sivonen Subject: Re: Difference of TEXT and XHTML? References: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> <41F8549C.3000904@intertwingly.net> <46BD6BB9-7034-11D9-B1FA-003065B8CF0E@iki.fi> <54DCCFA2-7066-11D9-B1FA-003065B8CF0E@iki.fi> <41F8EDEC.6050705@intertwingly.net> <8AFF49E7-7072-11D9-9153-000A95DC3D90@mac.com> In-Reply-To: <8AFF49E7-7072-11D9-9153-000A95DC3D90@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 27 Jan 2005, at 1:34 pm, Sam Ruby wrote: > >>> http://www.intertwingly.net/wiki/pie/PaceTypeTextRedundant >> >> >> There are cases where explicit is better than implicit. > > > Yes. It's more a psychological rather than a technical difference, but > I think it's important (it's like the difference between ASCII and > UTF-8). > > -1 on the pace. > -1 as well. Allowing people to assert they are using a subset of what's available is not a design error. > Graham > > (PS Are line breaks in Text mode honored?) The current text says whitespace collapsing is allowed. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Jan 27 12:04: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 MAA29992 for ; Thu, 27 Jan 2005 12:04: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 j0RGtN1I033934; Thu, 27 Jan 2005 08:55: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 j0RGtN6Z033933; Thu, 27 Jan 2005 08:55:23 -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 j0RGtLxJ033908 for ; Thu, 27 Jan 2005 08:55:21 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-12.adsl-net.finnetcom.net ([217.140.228.12]:53131 "EHLO [217.140.228.12]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228829AbVA0QzD (ORCPT ); Thu, 27 Jan 2005 18:55:03 +0200 In-Reply-To: <8AFF49E7-7072-11D9-9153-000A95DC3D90@mac.com> References: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> <41F8549C.3000904@intertwingly.net> <46BD6BB9-7034-11D9-B1FA-003065B8CF0E@iki.fi> <54DCCFA2-7066-11D9-B1FA-003065B8CF0E@iki.fi> <41F8EDEC.6050705@intertwingly.net> <8AFF49E7-7072-11D9-9153-000A95DC3D90@mac.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2EE12BE2-7084-11D9-B1FA-003065B8CF0E@iki.fi> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henri Sivonen Subject: Re: Difference of TEXT and XHTML? Date: Thu, 27 Jan 2005 18:55:00 +0200 To: Graham X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 27, 2005, at 16:48, Graham wrote: > (PS Are line breaks in Text mode honored?) The current spec text allows (IMO, it would be better to require) white-space normalization, so no line breaks are not honored. -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Thu Jan 27 12:07: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 MAA00174 for ; Thu, 27 Jan 2005 12:07: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 j0RGwBsI034135; Thu, 27 Jan 2005 08:58: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 j0RGwBhO034134; Thu, 27 Jan 2005 08:58:11 -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 j0RGtLxL033908 for ; Thu, 27 Jan 2005 08:58:10 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-12.adsl-net.finnetcom.net ([217.140.228.12]:53139 "EHLO [217.140.228.12]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228822AbVA0Q6K (ORCPT ); Thu, 27 Jan 2005 18:58:10 +0200 In-Reply-To: <38356220-707B-11D9-9797-000A95A51C9E@sun.com> References: <38356220-707B-11D9-9797-000A95A51C9E@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9E52FACC-7084-11D9-B1FA-003065B8CF0E@iki.fi> Content-Transfer-Encoding: 7bit Cc: Atom Syntax , Eric Scheid From: Henri Sivonen Subject: Re: Difference of TEXT and XHTML? Date: Thu, 27 Jan 2005 18:58:07 +0200 To: Tim Bray X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 27, 2005, at 17:50, Tim Bray wrote: > On Jan 27, 2005, at 4:46 AM, Eric Scheid wrote: > >> however, the spec says: >> >> The content SHOULD be XHTML text and markup that could >> validly appear directly within an xhtml:div element. >> >> which could lead others to make the same mistake I must have made. > > The easiest way to solve this, I think, is with examples. Avoiding the word "markup" would also help avoiding any associations with unparsed source. -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Thu Jan 27 12:08: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 MAA00361 for ; Thu, 27 Jan 2005 12:08: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 j0RH13Zi034340; Thu, 27 Jan 2005 09:01: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 j0RH13Ea034339; Thu, 27 Jan 2005 09:01: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 j0RGtLxN033908 for ; Thu, 27 Jan 2005 09:01:02 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-12.adsl-net.finnetcom.net ([217.140.228.12]:53144 "EHLO [217.140.228.12]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228884AbVA0RBC (ORCPT ); Thu, 27 Jan 2005 19:01:02 +0200 In-Reply-To: <1f2ed5cd050127071410abcb9f@mail.gmail.com> References: <03A4E7F4-6FDB-11D9-B1FA-003065B8CF0E@iki.fi> <41F8549C.3000904@intertwingly.net> <46BD6BB9-7034-11D9-B1FA-003065B8CF0E@iki.fi> <54DCCFA2-7066-11D9-B1FA-003065B8CF0E@iki.fi> <41F8EDEC.6050705@intertwingly.net> <8AFF49E7-7072-11D9-9153-000A95DC3D90@mac.com> <1f2ed5cd050127071410abcb9f@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <05587D22-7085-11D9-B1FA-003065B8CF0E@iki.fi> Content-Transfer-Encoding: 7bit Cc: Graham , Atom Syntax , Sam Ruby From: Henri Sivonen Subject: Re: Difference of TEXT and XHTML? Date: Thu, 27 Jan 2005 19:01:00 +0200 To: Danny Ayers X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 27, 2005, at 17:14, Danny Ayers wrote: > In the Rosy-tinted Description Framework, if the type could be fully > expressed using XML Schema datatypes, the Atom content element could > map nicely onto a XSD-datatyped literal. Problem is I couldn't see any > obvious way of distinguishing HTML from TEXT, as the former would be > escaped anyway. As a practical solution, you could use a SAX filter for converting HTML and TEXT to XHTML and then deal with only XHTML in the RDF mapping. -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Thu Jan 27 12:09: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 MAA00417 for ; Thu, 27 Jan 2005 12:09: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 j0RH0N68034285; Thu, 27 Jan 2005 09:00: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 j0RH0Nba034284; Thu, 27 Jan 2005 09:00:23 -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 j0RH0Mmd034273 for ; Thu, 27 Jan 2005 09:00: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 (sccrmhc11) with SMTP id <2005012717001201100ccjube>; Thu, 27 Jan 2005 17:00:12 +0000 Date: Thu, 27 Jan 2005 10:00:11 -0700 Subject: Re: Difference of TEXT and XHTML? 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 Thursday, January 27, 2005, at 12:47 AM, Eric Scheid wrote: > On 27/1/05 6:23 PM, "Henri Sivonen" wrote: >> But type='TEXT' is only a degenerate case of type='XHTML' >> (type='XHTML' >> with only text content). What value does type='TEXT' add to the format >> except the ability of feedvalidator.org to detect cases where there >> are >> element children although the author claims there are not, which >> suggests an authoring error? Does type='TEXT' intentionally exist only >> to add this feedvalidator.org value? > > maybe it exists so I can write a title which looks like this > > "I hate the tag" > > which is the plain text rendition, or if I wanted to code it in > html/xhtml > it would be > > "I hate the <blink> tag" > > and then applying XML escaping ... would be the following? ... > > I hate the &lt;blink&< tag > <span xmlns="http://www.w3.org/1999/xhtml">&copy;</span> </content> ...which seems to suggest that the above XHTML example should be: <title type="XHTML">I hate the <blink> tag or: <span xmlns="http://www.w3.org/1999/xhtml">I hate the &lt;blink&> tag</span> ...of course, it's difficult to say whether applications actually WOULD do it that way, or whether they'd treat the text as if it were in the XHTML namespace based on the @type value. Getting rid of @type="TEXT" could lead to a situation similar to RSS 2.0 where content that is intended to be rendered as plain text was being treated as markup. If people use @type="XHTML" without a namespace for content intended to be rendered as plain text, they'll still have this problem, but if they have the option of @type="TEXT", they'll have an unambiguous way to do it without having to add gratuitous markup. Thus, -1 on PaceTypeTextRedundant. Antone [1] http://www.imc.org/atom-syntax/mail-archive/msg04249.html From owner-atom-syntax@mail.imc.org Thu Jan 27 12:14: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 MAA01011 for ; Thu, 27 Jan 2005 12:14: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 j0RH3Zxg034501; Thu, 27 Jan 2005 09:03: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 j0RH3ZcX034500; Thu, 27 Jan 2005 09:03:35 -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 j0RH3ZLB034494 for ; Thu, 27 Jan 2005 09:03:35 -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 j0RH3Ydt022844 for ; Thu, 27 Jan 2005 10:03:34 -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 <0IAZ00601JDJIA@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Thu, 27 Jan 2005 12:03:33 -0500 (EST) Received: from localhost (vpn-129-150-32-98.Central.Sun.COM [129.150.32.98]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IAZ00F53JDQ55@bur-mail1.east.sun.com> for atom-syntax@imc.org; Thu, 27 Jan 2005 12:03:33 -0500 (EST) Received: from ndw by localhost with local (Exim 4.43) id 1CuD2z-0001bn-So for atom-syntax@imc.org; Thu, 27 Jan 2005 12:03:09 -0500 X-URL: http://nwalsh.com/ Date: Thu, 27 Jan 2005 12:03:04 -0500 From: Norman Walsh Subject: Multiple content allowed? To: Atom Syntax Message-id: <87d5vqyfcn.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 Someone sent me this, noting that it was not valid according to the grammar I posted. He thought it was legal according to the spec, and I'm not sure. What say you? Anonymous User Public Space Readings 2005-01-25T13:52:08Z Some Article Some notes Some Title 2005-01-25T13:52:08Z Be seeing you, norm =2D-=20 Norman Walsh | The lasting pleasures of contact with http://nwalsh.com/ | the natural world are not reserved for | scientists but are available to anyone | who will place himself under the | influence of the earth, sea and sky and | their amazing life.--Rachel Carson --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBB+R7IOyltUcwYWjsRAkBAAKCtpahDf33A65c+cRiSGZhlTLE7pQCgoEz4 epwIoQoGY+HXvMTgbG29lJs= =VkT9 -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Thu Jan 27 12:21: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 MAA02177 for ; Thu, 27 Jan 2005 12:21: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 j0RH7TUl034804; Thu, 27 Jan 2005 09:07: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 j0RH7TID034803; Thu, 27 Jan 2005 09:07:29 -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 j0RH7SJU034786 for ; Thu, 27 Jan 2005 09:07:28 -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 j0RH5xTr023947; Thu, 27 Jan 2005 12:07:15 -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 CLH91282 (AUTH bob@wyman.us); Thu, 27 Jan 2005 12:05:57 -0500 (EST) Message-Id: <200501271705.CLH91282@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Antone Roundy'" , Subject: RE: PaceIconAndImage Date: Thu, 27 Jan 2005 12:03:36 -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: AcUEj9wildnjJ6psQPq0Cx2SO8QmUQAAdJMw Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > Also, why limit this to feed/head, and not entry? So that Atom > feeds will be easily convertible to RSS 2.0? Converting *to* RSS 2.0 shouldn't be a goal or even a consideration in any Atom related discussions. Only conversion *from* RSS 2.0 is interesting. If Atom is guaranteed to be convertible both to and from RSS 2.0 then Atom can never be more than RSS 2.0 and a great deal of the effort and goodwill that has gone into Atom would be a complete waste of time. bob wyman From owner-atom-syntax@mail.imc.org Thu Jan 27 12: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 MAA02369 for ; Thu, 27 Jan 2005 12:22: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 j0RHCVnp035189; Thu, 27 Jan 2005 09:12: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 j0RHCV4I035188; Thu, 27 Jan 2005 09:12:31 -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 j0RHCU3k035181 for ; Thu, 27 Jan 2005 09:12:30 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 56504 messnum 1897458 invoked from network[213.94.211.166/mail2.newbay.com]); 27 Jan 2005 17:12:23 -0000 Received: from mail2.newbay.com (HELO ?192.168.213.135?) (213.94.211.166) by mail02.svc.cra.dublin.eircom.net (qp 56504) with SMTP; 27 Jan 2005 17:12:23 -0000 Message-ID: <41F920F5.8050400@dehora.net> Date: Thu, 27 Jan 2005 17:12:21 +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: PaceAttributesNamespace is *not* about syntax! References: <1f2ed5cd05012602474fc907a1@mail.gmail.com> <41F7A320.9020906@intertwingly.net> <8631b39ab59dd87f9ad947318c513654@bblfish.net> <3a0a09cffb909f5b93a3f6762f27f9e8@bblfish.net> <41F8FA79.4010906@dehora.net> <4306003c75fefe938dc569e28b7f88d0@bblfish.net> In-Reply-To: <4306003c75fefe938dc569e28b7f88d0@bblfish.net> 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 Henry Story wrote: > On 27 Jan 2005, at 15:28, Bill de hÓra wrote: > >> Rudeness objection. > > One reaps what one sows. [1] Should I counter by quoting from the Sermon on the Mount? > The problem is to clearly specify how extended atom documents like the > one above > are to be written consistently, so that they can be interpreted > correctly, the > way the writer of the document intended them to be. This might be over-egging it, but... I would say the above is not an extension to Atom (no new Atom names have been added). What would be good is a controlled way to associate new properties from whatever vocab to the entry, either as metadata (aboutness) or data (partness). An RDF mapping will provide that, but I'm not clear it needs to be part of the Atom format, since there doesn't seem to much demand for anything other than the ability to structurally add properties (via namespaces) outside the RDF community. OT: the single concern I have with Atom in this area is the link element, specifically @rel. Extension by attribute is an XML antipattern as best I can tell, and @rel strikes me as being bindweed rather than letting a thousand flowers bloom. Having said that, the market is innovating beyond what we're speccing here, so perhaps we should just stay out of the way. > The problem is that attributes in atom are not namespaced. If they were > then it > would be easy to interpret the above document as an rdf document. An rdf > document > has very clearly specified semantics. Having these clearly specified > semantics is > very helpful to extension writers and consumers. Is this not solvable by articulating how the RDF mapping should treat Atom specified (unprefixed) attributes and constraining future 3rd party attribute extensions to use a prefix? > Does this help? Yes, but I think it can be dealt with as outlined above, unless I'm missing something. cheers Bill From owner-atom-syntax@mail.imc.org Thu Jan 27 12:28: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 MAA03218 for ; Thu, 27 Jan 2005 12:28: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 j0RHFlc9035370; Thu, 27 Jan 2005 09:15: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 j0RHFllR035369; Thu, 27 Jan 2005 09:15:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail10.svc.cra.dublin.eircom.net (mail10.svc.cra.dublin.eircom.net [159.134.118.26]) by above.proper.com (8.12.11/8.12.9) with SMTP id j0RHFk5Z035358 for ; Thu, 27 Jan 2005 09:15:46 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 85828 messnum 1967069 invoked from network[213.94.211.166/mail2.newbay.com]); 27 Jan 2005 17:15:40 -0000 Received: from mail2.newbay.com (HELO ?192.168.213.135?) (213.94.211.166) by mail10.svc.cra.dublin.eircom.net (qp 85828) with SMTP; 27 Jan 2005 17:15:40 -0000 Message-ID: <41F921BA.1000008@dehora.net> Date: Thu, 27 Jan 2005 17:15:38 +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: Multiple content allowed? References: <87d5vqyfcn.fsf@nwalsh.com> In-Reply-To: <87d5vqyfcn.fsf@nwalsh.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 Norman Walsh wrote: > Someone sent me this, noting that it was not valid according to the > grammar I posted. He thought it was legal according to the spec, > and I'm not sure. What say you? My first thought is that unless there a use-case for multiple content blocks, you've found a bug in the spec. cheers Bill From owner-atom-syntax@mail.imc.org Thu Jan 27 12:40: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 MAA05192 for ; Thu, 27 Jan 2005 12:40: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 j0RHSBrZ036405; Thu, 27 Jan 2005 09:28: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 j0RHSBUl036404; Thu, 27 Jan 2005 09:28: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 j0RHSBA6036398 for ; Thu, 27 Jan 2005 09:28:11 -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 1CuDR9-0004th-A2; Thu, 27 Jan 2005 17:28:07 +0000 Message-ID: <41F924A7.6050104@franklinmint.fm> Date: Thu, 27 Jan 2005 12:28:07 -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: Multiple content allowed? References: <87d5vqyfcn.fsf@nwalsh.com> <41F921BA.1000008@dehora.net> In-Reply-To: <41F921BA.1000008@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: > > Norman Walsh wrote: > >> Someone sent me this, noting that it was not valid according to the >> grammar I posted. He thought it was legal according to the spec, >> and I'm not sure. What say you? > > > My first thought is that unless there a use-case for multiple content > blocks, you've found a bug in the spec. http://www.atompub.org/2005/01/10/draft-ietf-atompub-format-04.html#rfc.section.5.12 "atom:entry elements MUST contain zero or one atom:content elements." PaceReformedContent3 made multiple content elements invalid. I wonder why that example couldn't use an xhtml summary element. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Jan 27 12: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 MAA05541 for ; Thu, 27 Jan 2005 12:42: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 j0RHUbA7036533; Thu, 27 Jan 2005 09:30: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 j0RHUb8e036532; Thu, 27 Jan 2005 09:30: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 j0RHUbtt036520 for ; Thu, 27 Jan 2005 09:30: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 <2005012717303101100cfck4e>; Thu, 27 Jan 2005 17:30:32 +0000 Date: Thu, 27 Jan 2005 10:30:30 -0700 Subject: Mandatory method of specifying XHTML namespace? 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: <2463D57C-7089-11D9-9325-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 Given how common it is even for us, when posting examples of without declaring the XHTML namespace, might it be a good idea to specify a mandatory method of declaring the XHTML namespace to ensure that implementors don't forget? I realize that it could be done multiple ways, but would there be any drawback to mandating one? I'd suggest changing: 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. Receiving software which displays the content MAY use the markup to aid in displaying it. Escaped markup is interpreted as a text representation of markup, and MUST NOT be interpreted as markup itself. to something like: If the value of "type" is "XHTML", the content of the Text construct MUST be a single xhtml:div element which MUST declare the XHTML namespace, either as the default namespace or with a namespace prefix [[[we COULD require it to be the default namespace--any drawbacks to that?]]]. The xhtml:div element MAY contain child elements. Receiving software which displays the content MAY use any markup to aid in displaying it. Escaped markup is interpreted as a text representation of markup, and MUST NOT be interpreted as markup itself. Examples:
The word bold is bold.
The word bold is bold.
The word bold is bold.
 If I get no explanations of why this is a bad idea, I'll write a Pace. Antone From owner-atom-syntax@mail.imc.org Thu Jan 27 12:52: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 MAA06460 for ; Thu, 27 Jan 2005 12:52: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 j0RHUJKd036513; Thu, 27 Jan 2005 09:30: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 j0RHUJ2V036512; Thu, 27 Jan 2005 09:30:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [69.20.61.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0RHUI3m036504 for ; Thu, 27 Jan 2005 09:30:18 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [172.18.40.150] (nat-147-1.oreilly.com [209.204.147.1]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.10) with ESMTP id j0RHUGAL011857; Thu, 27 Jan 2005 12:30:16 -0500 Message-ID: <41F92528.9090009@intertwingly.net> Date: Thu, 27 Jan 2005 12:30:16 -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: Difference of TEXT and XHTML? References: In-Reply-To: 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 Antone Roundy wrote: > > On Thursday, January 27, 2005, at 12:47 AM, Eric Scheid wrote: > >> On 27/1/05 6:23 PM, "Henri Sivonen" wrote: >> >>> But type='TEXT' is only a degenerate case of type='XHTML' (type='XHTML' >>> with only text content). What value does type='TEXT' add to the format >>> except the ability of feedvalidator.org to detect cases where there are >>> element children although the author claims there are not, which >>> suggests an authoring error? Does type='TEXT' intentionally exist only >>> to add this feedvalidator.org value? >> >> maybe it exists so I can write a title which looks like this >> >> "I hate the tag" >> >> which is the plain text rendition, or if I wanted to code it in >> html/xhtml >> it would be >> >> "I hate the <blink> tag" >> >> and then applying XML escaping ... would be the following? ... >> >> I hate the &lt;blink&< tag >> in the XHTML namespace, ie. it's not this:) I did say that that's how it should be rendered (I forwarded to you my original email) but the reason has nothing to do with namespaces. > <content type="inline-xhtml"> > <span xmlns="http://www.w3.org/1999/xhtml">&copy;</span> > </content> > > ...which seems to suggest that the above XHTML example should be: > > <title type="XHTML">I hate the <blink> tag yes > or: > > <span xmlns="http://www.w3.org/1999/xhtml">I > hate the &lt;blink&> tag</span> no Clearly some examples ARE in order. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Jan 27 12:58: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 MAA06884 for ; Thu, 27 Jan 2005 12:58: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 j0RHknBt038236; Thu, 27 Jan 2005 09:46: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 j0RHknT2038235; Thu, 27 Jan 2005 09:46:49 -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 j0RHknCU038223 for ; Thu, 27 Jan 2005 09:46:49 -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 <2005012717464001200g3ojie>; Thu, 27 Jan 2005 17:46:40 +0000 Date: Thu, 27 Jan 2005 10:46:35 -0700 Subject: Re: Difference of TEXT and XHTML? 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: <41F92528.9090009@intertwingly.net> Message-Id: <638A1320-708B-11D9-9325-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 10:30 AM, Sam Ruby wrote: >> In a message sent off-list to me last June, which I no longer have, >> but referred to in a message on list[1], Sam said that: >> >> &copy; >> >> should be rendered "©", not as a copyright symbol (because it's >> not in the XHTML namespace, ie. it's not this:) > > I did say that that's how it should be rendered (I forwarded to you my > original email) but the reason has nothing to do with namespaces. > Recent reading, including this response, is leading me to believe that I'd misunderstood @type="XHTML". Questions: 1) Clearly, this cannot appear in an Atom feed, because © is not an XML entity: © What about this?
©
 2) If that is valid (I'm presuming that it is, and that it should be rendered as a copyright symbol), I'm wondering how many XML parsers are going to choke on it anyway. If that is NOT valid, then how would one put a copyright symbol (or any other XHTML entity that is not an XML entity) into XHTML content in an Atom feed? > Clearly some examples ARE in order. Yep. And if many XML parsers are going to choke on the above example, warnings too. Antone From owner-atom-syntax@mail.imc.org Thu Jan 27 12:58: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 MAA06911 for ; Thu, 27 Jan 2005 12:58: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 j0RHecqa037739; Thu, 27 Jan 2005 09:40: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 j0RHecMX037738; Thu, 27 Jan 2005 09:40: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 j0RHebMt037726 for ; Thu, 27 Jan 2005 09:40:37 -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 1CuDdB-0005Ab-SX; Thu, 27 Jan 2005 17:40:33 +0000 Message-ID: <41F92792.8010806@franklinmint.fm> Date: Thu, 27 Jan 2005 12:40:34 -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: Mandatory method of specifying XHTML namespace? References: <2463D57C-7089-11D9-9325-003065EA6144@geckotribe.com> In-Reply-To: <2463D57C-7089-11D9-9325-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: > > If I get no explanations of why this is a bad idea, I'll write a Pace. Every XHTML feed I've seen in the wild starts with a single div element +1. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Jan 27 13:22: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 NAA08839 for ; Thu, 27 Jan 2005 13:22: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 j0RI4dc9039605; Thu, 27 Jan 2005 10:04: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 j0RI4dsg039604; Thu, 27 Jan 2005 10:04:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [69.20.61.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0RI4cRC039596 for ; Thu, 27 Jan 2005 10:04:39 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [172.18.40.150] (nat-147-1.oreilly.com [209.204.147.1]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.10) with ESMTP id j0RI4aJ7016524; Thu, 27 Jan 2005 13:04:37 -0500 Message-ID: <41F92D35.1080307@intertwingly.net> Date: Thu, 27 Jan 2005 13:04:37 -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: Difference of TEXT and XHTML? References: <638A1320-708B-11D9-9325-003065EA6144@geckotribe.com> In-Reply-To: <638A1320-708B-11D9-9325-003065EA6144@geckotribe.com> 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 Antone Roundy wrote: > > On Thursday, January 27, 2005, at 10:30 AM, Sam Ruby wrote: > >>> In a message sent off-list to me last June, which I no longer have, >>> but referred to in a message on list[1], Sam said that: >>> >>> &copy; >>> >>> should be rendered "©", not as a copyright symbol (because it's >>> not in the XHTML namespace, ie. it's not this:) >> >> >> I did say that that's how it should be rendered (I forwarded to you my >> original email) but the reason has nothing to do with namespaces. >> > Recent reading, including this response, is leading me to believe that > I'd misunderstood @type="XHTML". Questions: > > 1) Clearly, this cannot appear in an Atom feed, because © is not an > XML entity: > > © > > What about this? > >
xmlns="http://www.w3.org/1999/xhtml">©
 Neither are well formed XML. Invoking a namespace does not implicitly provide you with additional entities. Using the XHTML DTD (not recommended in this case) woulld. > 2) If that is valid (I'm presuming that it is, and that it should be > rendered as a copyright symbol), I'm wondering how many XML parsers are > going to choke on it anyway. If that is NOT valid, then how would one > put a copyright symbol (or any other XHTML entity that is not an XML > entity) into XHTML content in an Atom feed? By definition, all XML parsers will choke on the latter. If not, they are not conformant. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Jan 27 13:45: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 NAA11046 for ; Thu, 27 Jan 2005 13:45: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 j0RIZeJL041843; Thu, 27 Jan 2005 10:35: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 j0RIZeP3041842; Thu, 27 Jan 2005 10:35: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 (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j0RIZdoP041798 for ; Thu, 27 Jan 2005 10:35:40 -0800 (PST) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 27 Jan 2005 18:35:31 -0000 Received: from dsl-082-083-163-015.arcor-ip.net (EHLO helix) (82.83.163.15) by mail.gmx.net (mp005) with SMTP; 27 Jan 2005 19:35:31 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Antone Roundy Cc: atom-syntax@imc.org Subject: Re: Difference of TEXT and XHTML? Date: Thu, 27 Jan 2005 19:36:15 +0100 Message-ID: <42082f5d.326093937@smtp.bjoern.hoehrmann.de> References: <41F92528.9090009@intertwingly.net> <638A1320-708B-11D9-9325-003065EA6144@geckotribe.com> In-Reply-To: <638A1320-708B-11D9-9325-003065EA6144@geckotribe.com> 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 * Antone Roundy wrote: >1) Clearly, this cannot appear in an Atom feed, because © is not >an XML entity: > > © > >What about this? > >
xmlns="http://www.w3.org/1999/xhtml">©
 That depends on whether the document has a document type declaration and if how it looks like. And on various properties of the XML processor and the application using it, as well as on various dynamic conditions. E.g. whether the document type declaration refers to an external subset and whether the processor attempts to resolve the reference. If there is no document type declaration, the document would not be well-formed. >2) If that is valid (I'm presuming that it is, and that it should be >rendered as a copyright symbol), I'm wondering how many XML parsers are >going to choke on it anyway. If that is NOT valid, then how would one >put a copyright symbol (or any other XHTML entity that is not an XML >entity) into XHTML content in an Atom feed? There are two ways to refer to such characters, either by literally in- cluding them (in very much the same way as you've included "X" and "L" in your example) or by using character references ala
; Thu, 27 Jan 2005 13:45: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 j0RIaWQZ041929; Thu, 27 Jan 2005 10:36: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 j0RIaW6F041928; Thu, 27 Jan 2005 10:36:32 -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 j0RIaVva041921 for ; Thu, 27 Jan 2005 10:36:31 -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 j0RIaVVu003798 for ; Thu, 27 Jan 2005 11:36:31 -0700 (MST) Received: from xpa-fe1 (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 <0IAZ00AUENOUHV@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 27 Jan 2005 11:36:31 -0700 (MST) Received: from [192.168.1.4] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAZ005B4NOTC5@mail.sun.net> for atom-syntax@imc.org; Thu, 27 Jan 2005 11:36:30 -0700 (MST) Date: Thu, 27 Jan 2005 10:36:29 -0800 From: Tim Bray Subject: Re: Mandatory method of specifying XHTML namespace? In-reply-to: <2463D57C-7089-11D9-9325-003065EA6144@geckotribe.com> To: Antone Roundy Cc: atom-syntax@imc.org Message-id: <5BC232A6-7092-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: <2463D57C-7089-11D9-9325-003065EA6144@geckotribe.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 27, 2005, at 9:30 AM, Antone Roundy wrote: > If the value of "type" is "XHTML", the content of the Text construct > MUST be a single xhtml:div element which MUST declare the XHTML > namespace, either as the default namespace or with a namespace prefix > [[[we COULD require it to be the default namespace--any drawbacks to > that?]]]. The xhtml:div element MAY contain child elements. > Receiving software which displays the content MAY use any markup to > aid in displaying it. Escaped markup is interpreted as a text > representation of markup, and MUST NOT be interpreted as markup > itself. I'd probably be +1 on that. No, it would be way out of bounds-bad XML practice-to talk about whether it's the default namespace or some explicit namespace. -Tim From owner-atom-syntax@mail.imc.org Thu Jan 27 13:45: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 NAA11156 for ; Thu, 27 Jan 2005 13:45: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 j0RIamwd041962; Thu, 27 Jan 2005 10:36: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 j0RIamFq041961; Thu, 27 Jan 2005 10:36:48 -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 j0RIamPL041950 for ; Thu, 27 Jan 2005 10:36: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 (rwcrmhc11) with SMTP id <2005012718363601300kei76e>; Thu, 27 Jan 2005 18:36:36 +0000 Date: Thu, 27 Jan 2005 11:36:35 -0700 Subject: Re: Difference of TEXT and XHTML? 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: <41F92D35.1080307@intertwingly.net> Message-Id: <5F800F1A-7092-11D9-9325-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 11:04 AM, Sam Ruby wrote: >> Recent reading, including this response, is leading me to believe >> that I'd misunderstood @type="XHTML". Questions: >> 1) Clearly, this cannot appear in an Atom feed, because © is not >> an XML entity: >> © >> What about this? >>
> xmlns="http://www.w3.org/1999/xhtml">©
 > > Neither are well formed XML. Invoking a namespace does not implicitly > provide you with additional entities. Using the XHTML DTD (not > recommended in this case) woulld. Ah yes, of course. It's amazing how obvious things can be the instant they're explained even slightly. So, what limitations are we running into with @type="XHTML"? 1) Can't use non-XML entities. 2) Can't use CSS classes and IDs--this is true of @type="HTML" too, of course. Any others? Any solutions? Do we WANT to solve these? Not in version 1.0? From owner-atom-syntax@mail.imc.org Thu Jan 27 14: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 OAA16265 for ; Thu, 27 Jan 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 j0RJWLpk046218; Thu, 27 Jan 2005 11:32: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 j0RJWLRa046217; Thu, 27 Jan 2005 11:32:21 -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 j0RJWLe2046209 for ; Thu, 27 Jan 2005 11:32:21 -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 <2005012719321501400hff8fe>; Thu, 27 Jan 2005 19:32:15 +0000 Date: Thu, 27 Jan 2005 12:32:13 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceXhtmlNamespaceDiv posted From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <25532B82-709A-11D9-9325-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/PaceXhtmlNamespaceDiv Abstract 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. Status Open Rationale 1. Given that even we often forget when writing examples to declare the XHTML namespace for XHTML text constructs and content elements, it seems likely that people producing actual feeds will forget to do so unless the requirement to do so is stated prominently and unambiguously. 2. Mandating a specific method of declaring the XHTML namespace will ensure uniformity between feeds. Proposal Replace the paragraph on XHTML in section 3.1.1 of draft-ietf-atompub-format-04.txt with the following: If the value of "type" is "XHTML", the content of the Text construct MUST be a single xhtml:div element which MUST declare the XHTML namespace. The xhtml:div MAY contain XHTML text and markup that could validly appear directly within an xhtml:div element. Receiving software which displays the content MAY use the markup to aid in displaying it. Escaped markup is interpreted as a text representation of markup, and MUST NOT be interpreted as markup itself. Examples:
This is XHTML content.
This is XHTML content.
 Replace the text of item 3 in section 5.12.3 with the same paragraph, and put the examples (and examples of the other types) after the list, with "summary" changed to "content". Impacts This is the common method of including XHTML content in existing Atom feeds, so the impact on existing implementations should be minimal to nil. From owner-atom-syntax@mail.imc.org Thu Jan 27 14:51: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 OAA16489 for ; Thu, 27 Jan 2005 14:51: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 j0RJcfcb046522; Thu, 27 Jan 2005 11: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 j0RJcfHE046521; Thu, 27 Jan 2005 11:38: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.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0RJceZv046515 for ; Thu, 27 Jan 2005 11:38:41 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so257730rnz for ; Thu, 27 Jan 2005 11:38:40 -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=Hxh7fIjWE3h18VZN0P4v5faMHUdkQUoQSeky+WiN0jHkiGUaFJU+4vMyg/cjPLBPRnM1kXmbMRJ2ifkEIIb0YyOSlh9kgVV5LntCCYyhxB+X1UYa9MpnG7V0KN9Ivhe+CDU/pt9IEG+A+YqO56qmEYoeZUpBpSwaG8TT0ap6jMQ= Received: by 10.38.179.46 with SMTP id b46mr225945rnf; Thu, 27 Jan 2005 11:38:40 -0800 (PST) Received: by 10.38.179.71 with HTTP; Thu, 27 Jan 2005 11:38:40 -0800 (PST) Message-ID: <1f2ed5cd05012711385a4dd89e@mail.gmail.com> Date: Thu, 27 Jan 2005 20:38:40 +0100 From: Danny Ayers Reply-To: Danny Ayers To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: PaceAttributesNamespace is *not* about syntax! Cc: Atom Syntax In-Reply-To: <41F920F5.8050400@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <1f2ed5cd05012602474fc907a1@mail.gmail.com> <41F7A320.9020906@intertwingly.net> <8631b39ab59dd87f9ad947318c513654@bblfish.net> <3a0a09cffb909f5b93a3f6762f27f9e8@bblfish.net> <41F8FA79.4010906@dehora.net> <4306003c75fefe938dc569e28b7f88d0@bblfish.net> <41F920F5.8050400@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0RJcfZv046516 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 27 Jan 2005 17:12:21 +0000, Bill de hÓra wrote: > > Henry Story wrote: > > On 27 Jan 2005, at 15:28, Bill de hÓra wrote: > > > >> Rudeness objection. > > > > One reaps what one sows. [1] > > Should I counter by quoting from the Sermon on the Mount? Blessed are the feedmakers. > What would be good is a controlled way to associate new properties from > whatever vocab to the entry, either as metadata (aboutness) or data > (partness). Yep, that's essentially what I've been chasing all along. > An RDF mapping will provide that, but I'm not clear it needs to be part > of the Atom format, since there doesn't seem to much demand for anything > other than the ability to structurally add properties (via namespaces) > outside the RDF community. Yes and no - there is demand for this kind of thing, is the RSS 1.0 community the same as the RDF community? There's a lot of additions around there... Whatever, even with RSS 2.0 there's Easy News Topics and all the stuff associated with media (enclosures + Yahoo's extensions) as good examples. > OT: the single concern I have with Atom in this area is the link > element, specifically @rel. Extension by attribute is an XML antipattern > as best I can tell, and @rel strikes me as being bindweed rather than > letting a thousand flowers bloom. Having said that, the market is > innovating beyond what we're speccing here, so perhaps we should just > stay out of the way. Hmm, maybe, but if the Technorati stuff and even rel="nofollow" are anything to go by, the bindweed can carry low-hanging fruit. > > The problem is that attributes in atom are not namespaced. If they were > > then it > > would be easy to interpret the above document as an rdf document. An rdf > > document > > has very clearly specified semantics. Having these clearly specified > > semantics is > > very helpful to extension writers and consumers. > > Is this not solvable by articulating how the RDF mapping should treat > Atom specified (unprefixed) attributes and constraining future 3rd party > attribute extensions to use a prefix? (Presumably also barring 3rd parties from reusing Atom attributes in those extensions). My concern there is with extension development outside of the RDF community. Without some uniform interpretation of the attributes outside of the context of an Atom document, there's scope for unwanted interactions. Assigning the things global names (URIs), even if they aren't explicitly expressed in Atom documents seems a low cost solution. > > Does this help? > > Yes, but I think it can be dealt with as outlined above, unless I'm > missing something. Non-RDF extensions. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Jan 27 14:54: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 OAA16685 for ; Thu, 27 Jan 2005 14:54: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 j0RJjekO046967; Thu, 27 Jan 2005 11:45: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 j0RJjePo046966; Thu, 27 Jan 2005 11:45:40 -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 j0RJjd2w046954 for ; Thu, 27 Jan 2005 11:45:39 -0800 (PST) (envelope-from fora@annevankesteren.nl) Received: (qmail 18236 invoked by uid 10); 27 Jan 2005 19:45:33 -0000 Received: (vexira-qq 18206-3F0911BD invoked from network) 27 Jan 2005 20:45:32 +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 < >; 27 Jan 2005 19:45:32 -0000 Message-ID: <41F944E4.9010101@annevankesteren.nl> Date: Thu, 27 Jan 2005 20:45:40 +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: PaceXhtmlNamespaceDiv posted References: <25532B82-709A-11D9-9325-003065EA6144@geckotribe.com> In-Reply-To: <25532B82-709A-11D9-9325-003065EA6144@geckotribe.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.5; VDF: 6.29.0.52; 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: > http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv > > If the value of "type" is "XHTML", the content of the Text construct > MUST be a single xhtml:div element which MUST declare the XHTML > namespace. The xhtml:div MAY contain XHTML text and markup that could > validly appear directly within an xhtml:div element. Receiving > software which displays the content MAY use the markup to aid in > displaying it. Escaped markup is interpreted as a text representation > of markup, and MUST NOT be interpreted as markup itself. Namespace prefixes are still allowed? > Examples: > >
style="color:#03c;">This is XHTML content.
 Can't we forbid the STYLE attribute? Or define a subset of allowed elements/attribute? It would help a bit if we declare what XHTML DTD we are following. It would suck that when XHTML 2.0 is released we allow people to enter it directly without updating the Atom specification. >
xmlns:xhtml="http://www.w3.org/1999/xhtml">This is > XHTML content.
 This DIV element != xhtml:div so this example would be invalid, right? -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Thu Jan 27 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 PAA20065 for ; Thu, 27 Jan 2005 15:18: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 j0RJwxkB047742; Thu, 27 Jan 2005 11:58: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 j0RJwx7B047741; Thu, 27 Jan 2005 11:58:59 -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 j0RJwwKa047735 for ; Thu, 27 Jan 2005 11:58:58 -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 j0RJwwVu007546 for ; Thu, 27 Jan 2005 12:58:58 -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 <0IAZ00865RIA4O@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 27 Jan 2005 12:58:58 -0700 (MST) Received: from [192.168.1.4] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAZ0054TRI9UK@mail.sun.net> for atom-syntax@imc.org; Thu, 27 Jan 2005 12:58:57 -0700 (MST) Date: Thu, 27 Jan 2005 11:58:56 -0800 From: Tim Bray Subject: Re: PaceXhtmlNamespaceDiv posted In-reply-to: <25532B82-709A-11D9-9325-003065EA6144@geckotribe.com> To: Antone Roundy Cc: 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: <25532B82-709A-11D9-9325-003065EA6144@geckotribe.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 27, 2005, at 11:32 AM, Antone Roundy wrote: > If the value of "type" is "XHTML", the content of the Text construct > MUST be a single xhtml:div element which MUST declare the XHTML > namespace. The xhtml:div MAY contain XHTML s/MAY/SHOULD/, surely? > text and markup that could validly appear directly within an > xhtml:div element. Receiving software which displays the content MAY > use the markup to aid in displaying it. Escaped markup is interpreted > as a text representation of markup, and MUST NOT be interpreted as > markup itself. From owner-atom-syntax@mail.imc.org Thu Jan 27 15:25: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 PAA21159 for ; Thu, 27 Jan 2005 15:25: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 j0RK9bTZ048367; Thu, 27 Jan 2005 12:09: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 j0RK9b0A048366; Thu, 27 Jan 2005 12:09: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 j0RK9bLT048359 for ; Thu, 27 Jan 2005 12:09: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 <2005012720093101100ccg7ke>; Thu, 27 Jan 2005 20:09:31 +0000 Date: Thu, 27 Jan 2005 13:09:30 -0700 Subject: Re: PaceXhtmlNamespaceDiv 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: <41F944E4.9010101@annevankesteren.nl> Message-Id: <5A44F6D6-709F-11D9-9325-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 12:45 PM, Anne van Kesteren wrote: >>
> xmlns:xhtml="http://www.w3.org/1999/xhtml">This is >> XHTML content.
 > > This DIV element != xhtml:div so this example would be invalid, right? > Oops. Fixed it. From owner-atom-syntax@mail.imc.org Thu Jan 27 15:25: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 PAA21183 for ; Thu, 27 Jan 2005 15:25: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 j0RKIeQR048976; Thu, 27 Jan 2005 12: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 j0RKIepH048975; Thu, 27 Jan 2005 12:18:40 -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 j0RKIRki048831 for ; Thu, 27 Jan 2005 12:18: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 <2005012720171301400hd3gve>; Thu, 27 Jan 2005 20:17:13 +0000 Date: Thu, 27 Jan 2005 13:17:11 -0700 Subject: Re: PaceXhtmlNamespaceDiv 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: <6D24E004-70A0-11D9-9325-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 12:58 PM, Tim Bray wrote: > On Jan 27, 2005, at 11:32 AM, Antone Roundy wrote: > >> If the value of "type" is "XHTML", the content of the Text construct >> MUST be a single xhtml:div element which MUST declare the XHTML >> namespace. The xhtml:div MAY contain XHTML > > s/MAY/SHOULD/, surely? > >> text and markup that could validly appear directly within an >> xhtml:div element. Receiving software which displays the content MAY >> use the markup to aid in displaying it. Escaped markup is interpreted >> as a text representation of markup, and MUST NOT be interpreted as >> markup itself. > Yes, but getting the wording precise without being too verbose is a little tricky. The reason I wrote MAY is that it could conceivably be empty, or it could contain just text OR markup. Here would be the bullet proof but slightly wordy version: The content of the xhtml:div, if any, MUST be XHTML text and/or markup that could validly appear directly within an xhtml:div element. Any better ideas, anyone? From owner-atom-syntax@mail.imc.org Thu Jan 27 15:38: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 PAA22228 for ; Thu, 27 Jan 2005 15:38: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 j0RKUoqD051094; Thu, 27 Jan 2005 12: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 j0RKUohL051093; Thu, 27 Jan 2005 12:30:50 -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 j0RKUn8h051068 for ; Thu, 27 Jan 2005 12:30:49 -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 <2005012720304101300ke8jde>; Thu, 27 Jan 2005 20:30:42 +0000 Date: Thu, 27 Jan 2005 13:30:40 -0700 Subject: Re: PaceXhtmlNamespaceDiv 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: <41F944E4.9010101@annevankesteren.nl> Message-Id: <4F53DB25-70A2-11D9-9325-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 12:45 PM, Anne van Kesteren wrote: >>
> style="color:#03c;">This is XHTML content.
 > > Can't we forbid the STYLE attribute? Or define a subset of allowed > elements/attribute? > On this mandatory div, or everywhere? If we forbid it on this div, we'll end up with:
This is XHTML content.
Is that preferable? As far as the question of CSS and/or elements/tags everywhere, I'd think that would be a matter for the security considerations section (protecting against the Raging Platypus, for example). Whatever restrictions we may pronounce, consumers will still have to include code to protect against abuses. And these issues apply equally to HTML as to XHTML. I'm not in favor of mandating restrictions, because there are probably legitimate uses for anything we might try to protect people against. From owner-atom-syntax@mail.imc.org Thu Jan 27 15:40: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 PAA22360 for ; Thu, 27 Jan 2005 15:40: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 j0RKTsBq051013; Thu, 27 Jan 2005 12:29: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 j0RKTsFn051012; Thu, 27 Jan 2005 12:29: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 j0RKTrNB051002 for ; Thu, 27 Jan 2005 12:29:54 -0800 (PST) (envelope-from fora@annevankesteren.nl) Received: (qmail 13297 invoked by uid 10); 27 Jan 2005 20:29:47 -0000 Received: (vexira-qq 13279-62D0BEB invoked from network) 27 Jan 2005 21:29:47 +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 < >; 27 Jan 2005 20:29:47 -0000 Message-ID: <41F94F43.7010809@annevankesteren.nl> Date: Thu, 27 Jan 2005 21:29:55 +0100 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: atom-syntax@imc.org Subject: Re: Issues with draft-ietf-atompub-format-04 References: <41F60A5C.1060308@annevankesteren.nl> <41F6DE44.8020906@franklinmint.fm> In-Reply-To: <41F6DE44.8020906@franklinmint.fm> 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: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: >> * 3.1.1 "type" Attribute >> >> I was wondering how I can include MathML in Atom posts or simple >> SVG fragments. If there are extension mechanisms available, >> shouldn't 3.1.1 refer to those? > > You can put it in atom:content. Other core elements are there to > provide a *baseline*. So I can not include MathML in the TITLE of my weblog? I do not see why this restriction is necessary. >> * 3.5.1 "rel" Attribute >> >> Why are the only values defined "alternate" and "related"? I have >> implemented "via" for a long time on my personal weblog and some >> aggregators have even implemented support for it. I consider it to >> be quite useful. > > Write a Pace. I would support it. Ok. I'll try to create one. >> * 3.5.2 "type" Attribute >> >> It is a bit vague that this TYPE attribute differs from the one in >> section 3.1.1. Where this one MUST have a MIME type as value the >> other MUST NOT. > > This is incorrect. I saw you rectified that statement in another e-mail. >> * 3.5.4 "hreflang" Attribute >> >> What I do not understand is that Atom provides a mechanism for >> linking to translations of the entry but does not provide a >> mechanism to include the actual translation. (For example, by >> allowing only a single TITLE element instead of allowing multiple >> if the value of the xml:lang attribute is different.) > > People are not born with Atom documents in their hands. We don't need > to provide for every eventuality. In Europe there are lots of different languages. It does not make sense to provide a feed based on language negotiation since feed aggregators do not support that. Either Atom should provide support for multiple languages or we should address something like feed language negotiation in the specification. >> * 4.1 "version" Attribute >> >> Does this attribute imply the feed has to be downloaded first >> before the aggregator knows if it supports the Atom format used? >> Can this not be solved by a MIME type parameter or is that going to >> difficult to implement? > > I think "version" should be dropped. We can always add it later. True. But that does not help current aggregators. At least, they will not reject new feeds. They will just found out they can not parse them at some point. >> * 4.2.2 "atom:link" Element >> >> It does not make sense to only allow a single "alternate" link >> construct if the TYPE attribute has the same value. What if I have >> translations of the document in question? For example: > > I agree. I think we should allow one or more. Does this change require or pace or is this enough? >> * 5.4 "atom:edit" Element >> >> Why does the specification not define that this MUST be a URI and >> how this URI MUST be processed as is done in for example 3.5.3? > > It does. See "Service Construct". Can this be referenced from within the specification? As in "See section ..." >> * 5.8 "atom:id" Element >> >> What type of content does this element contain? A URI, a string? >> How should it be created? How can I make sure, as a publisher that >> my atom:id value is universally unique and always will be? > > See "Identity Construct". Same as above. Plus, you did not answer my second question. >> * 5.12.1 "type" attribute >> >> This makes the TYPE attribute suck even more, IMHO. Can the Atom WG >> not introduce a second attribute? I believe we had MODE and TYPE >> some time ago. > > Co-constraints suck. @mode would be a multiplier on the ones we > already have. Two definitions as attribute value suck more IMHO. Especially since TYPE can cause confusion with html:type since we have adopted more from HTML. (Like the LINK element, several attributes.) >> * 5.12.2 "src" attribute >> >> How about fallback content? What is meant with "should be local"? >> For example, what do I do if I want to include a large SVG graphic >> in my feed which has the MIME type "image/svg+xml". Should I >> include it into the feed? > > You have lots of options that don't require "fallback content". We > rejected xhtml:object a long time ago. This again, only answers the first question. By the way, I guess I could just do:
buz
From owner-atom-syntax@mail.imc.org Thu Jan 27 15:42: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 PAA22603 for ; Thu, 27 Jan 2005 15: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 j0RKWQB9051215; Thu, 27 Jan 2005 12:32: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 j0RKWQeO051214; Thu, 27 Jan 2005 12:32:26 -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 j0RKWP0x051194 for ; Thu, 27 Jan 2005 12:32:25 -0800 (PST) (envelope-from fora@annevankesteren.nl) Received: (qmail 22591 invoked by uid 10); 27 Jan 2005 20:32:20 -0000 Received: (vexira-qq 22574-79372225 invoked from network) 27 Jan 2005 21:32:20 +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 < >; 27 Jan 2005 20:32:20 -0000 Message-ID: <41F94FDC.9000007@annevankesteren.nl> Date: Thu, 27 Jan 2005 21:32:28 +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: PaceXhtmlNamespaceDiv posted References: <6D24E004-70A0-11D9-9325-003065EA6144@geckotribe.com> In-Reply-To: <6D24E004-70A0-11D9-9325-003065EA6144@geckotribe.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.5; VDF: 6.29.0.52; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: >>> If the value of "type" is "XHTML", the content of the Text >>> construct MUST be a single xhtml:div element which MUST declare >>> the XHTML namespace. The xhtml:div MAY contain XHTML >> >> s/MAY/SHOULD/, surely? > > Yes, but getting the wording precise without being too verbose is a > little tricky. The reason I wrote MAY is that it could conceivably be > empty, or it could contain just text OR markup. Here would be the > bullet proof but slightly wordy version: > > The content of the xhtml:div, if any, MUST be XHTML text and/or > markup that could validly appear directly within an xhtml:div > element. > > Any better ideas, anyone? The content of the xhtml:div element MUST be XHTML or empty. TEXT and other things are also inside of the XHTML thing. By the way, does this exclude MathML and other things that can be easy mixed with XHTML? -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Thu Jan 27 15:48: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 PAA22979 for ; Thu, 27 Jan 2005 15:48: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 j0RKdAB7052103; Thu, 27 Jan 2005 12: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 j0RKdAY5052102; Thu, 27 Jan 2005 12:39: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 j0RKd91j052095 for ; Thu, 27 Jan 2005 12:39:09 -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 1CuGPx-0008Jz-29; Thu, 27 Jan 2005 20:39:05 +0000 Message-ID: <41F95168.7050908@franklinmint.fm> Date: Thu, 27 Jan 2005 15:39:04 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anne van Kesteren CC: atom-syntax@imc.org Subject: Re: Issues with draft-ietf-atompub-format-04 References: <41F60A5C.1060308@annevankesteren.nl> <41F6DE44.8020906@franklinmint.fm> <41F94F43.7010809@annevankesteren.nl> In-Reply-To: <41F94F43.7010809@annevankesteren.nl> Content-Type: text/plain; charset=UTF-8; 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 Anne van Kesteren wrote: > > So I can not include MathML in the TITLE of my weblog? I do not see > why this restriction is necessary. Nope. Can any aggregator display it? I wonder if Shrook users are filling Graham's inbox with requests for MathML in their titles. > In Europe there are lots of different languages. It does not make > sense to provide a feed based on language negotiation since feed > aggregators do not support that. There are lots of different languages in America, too! > > Either Atom should provide support for multiple languages or we should > address something like feed language negotiation in the specification. If what you say is true, then aggregators don't support multiple alternatives at all right now. Content Negotiation is covered by RFC2616. >> >> I think "version" should be dropped. We can always add it later. > > > True. But that does not help current aggregators. At least, they will > not reject new feeds. They will just found out they can not parse them > at some point. > The namespace will change. > >>> * 4.2.2 "atom:link" Element >>> >>> It does not make sense to only allow a single "alternate" link >>> construct if the TYPE attribute has the same value. What if I have >>> translations of the document in question? For example: >> >> >> I agree. I think we should allow one or more. > > > Does this change require or pace or is this enough? I don't know. >>> * 5.4 "atom:edit" Element >>> >>> Why does the specification not define that this MUST be a URI and >>> how this URI MUST be processed as is done in for example 3.5.3? >> >> >> It does. See "Service Construct". > > > Can this be referenced from within the specification? As in "See > section ..." Sure. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Jan 27 15:48: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 PAA23021 for ; Thu, 27 Jan 2005 15:48: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 j0RKe3c5052176; Thu, 27 Jan 2005 12: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 j0RKe3Br052175; Thu, 27 Jan 2005 12:40: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 j0RKe2md052155 for ; Thu, 27 Jan 2005 12:40: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 (rwcrmhc11) with SMTP id <2005012720395701300k81v8e>; Thu, 27 Jan 2005 20:39:57 +0000 Date: Thu, 27 Jan 2005 13:39:56 -0700 Subject: Re: PaceXhtmlNamespaceDiv 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: <41F94FDC.9000007@annevankesteren.nl> Message-Id: <9AB0AB28-70A3-11D9-9325-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 01:32 PM, Anne van Kesteren wrote: > Antone Roundy wrote: >>>> If the value of "type" is "XHTML", the content of the Text >>>> construct MUST be a single xhtml:div element which MUST declare >>>> the XHTML namespace. The xhtml:div MAY contain XHTML >>> s/MAY/SHOULD/, surely? >> Yes, but getting the wording precise without being too verbose is a >> little tricky. The reason I wrote MAY is that it could conceivably be >> empty, or it could contain just text OR markup. Here would be the >> bullet proof but slightly wordy version: >> The content of the xhtml:div, if any, MUST be XHTML text and/or >> markup that could validly appear directly within an xhtml:div >> element. >> Any better ideas, anyone? > > The content of the xhtml:div element MUST be XHTML or empty. > > TEXT and other things are also inside of the XHTML thing. By the way, > does this exclude MathML and other things that can be easy mixed with > XHTML? > How about if we remove "XHTML", changing it to this: The content of the xhtml:div, if any, MUST be text and/or markup that could validly appear directly within an xhtml:div element. Thus, if MathML can be mixed in with XHTML in a div, it's allowed. Perhaps "directly" could be removed too. From owner-atom-syntax@mail.imc.org Thu Jan 27 15:49: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 PAA23098 for ; Thu, 27 Jan 2005 15:49: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 j0RKeDJQ052194; Thu, 27 Jan 2005 12:40: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 j0RKeDDH052193; Thu, 27 Jan 2005 12:40: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 j0RKeCE9052153 for ; Thu, 27 Jan 2005 12:40:12 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-12.adsl-net.finnetcom.net ([217.140.228.12]:54030 "EHLO [217.140.228.12]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228809AbVA0Ujw (ORCPT ); Thu, 27 Jan 2005 22:39:52 +0200 In-Reply-To: <2463D57C-7089-11D9-9325-003065EA6144@geckotribe.com> References: <2463D57C-7089-11D9-9325-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <96ADD67E-70A3-11D9-B1FA-003065B8CF0E@iki.fi> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org From: Henri Sivonen Subject: Re: Mandatory method of specifying XHTML namespace? Date: Thu, 27 Jan 2005 22:39:49 +0200 To: Antone Roundy X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 27, 2005, at 19:30, Antone Roundy wrote: > Given how common it is even for us, when posting examples of type="XHTML"> without declaring the XHTML namespace, might it be a > good idea to specify a mandatory method of declaring the XHTML > namespace to ensure that implementors don't forget? +1 That should be obvious. > If the value of "type" is "XHTML", the content of the Text construct > MUST be a single xhtml:div element -1 gratuitous element cruft. The text construct element itself serves as a container. > which MUST declare the XHTML namespace, either as the default > namespace or with a namespace prefix -1 Atom should not micro-manage how and on which elements namespace declarations appear. Feed in the wild that declares the namespaces on root: http://macsanomat.fi/atom -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Thu Jan 27 15:50: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 PAA23162 for ; Thu, 27 Jan 2005 15:50: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 j0RKbIT4051753; Thu, 27 Jan 2005 12: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 j0RKbIFc051752; Thu, 27 Jan 2005 12:37:18 -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 j0RKbIFp051741 for ; Thu, 27 Jan 2005 12:37: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 (rwcrmhc11) with SMTP id <2005012720371201300kc4i0e>; Thu, 27 Jan 2005 20:37:12 +0000 Date: Thu, 27 Jan 2005 13:37:11 -0700 Subject: Re: PaceXhtmlNamespaceDiv 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: <25532B82-709A-11D9-9325-003065EA6144@geckotribe.com> Message-Id: <3894F57A-70A3-11D9-9325-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 12:32 PM, Antone Roundy wrote: > If the value of "type" is "XHTML", the content of the Text construct > MUST be a single xhtml:div element which MUST declare the XHTML > namespace. Would it be too picky to assert that this language doesn't allow whitespace before and after the div? Do we WANT to forbid such whitespace? If not, does the language need to be adjusted? From owner-atom-syntax@mail.imc.org Thu Jan 27 16:03: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 QAA24534 for ; Thu, 27 Jan 2005 16:03: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 j0RKrdks053106; Thu, 27 Jan 2005 12:53: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 j0RKrdLj053105; Thu, 27 Jan 2005 12:53:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0RKrbkd053097 for ; Thu, 27 Jan 2005 12:53:37 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23410; Thu, 27 Jan 2005 15:53:32 -0500 (EST) Message-Id: <200501272053.PAA23410@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: atom-syntax@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atompub-format-05.txt Date: Thu, 27 Jan 2005 15:53:31 -0500 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF. Title : The Atom Syndication Format Author(s) : M. Nottingham, R. Sayre Filename : draft-ietf-atompub-format-05.txt Pages : 37 Date : 2005-1-27 This document specifies Atom, an XML-based Web content and metadata syndication format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-atompub-format-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-atompub-format-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-27143850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atompub-format-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atompub-format-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-27143850.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-atom-syntax@mail.imc.org Thu Jan 27 16: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 QAA25342 for ; Thu, 27 Jan 2005 16: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 j0RKnbvs052792; Thu, 27 Jan 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 j0RKnbv5052791; Thu, 27 Jan 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 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 j0RKnN8s052775 for ; Thu, 27 Jan 2005 12:49:37 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 9998 messnum 2832456 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 27 Jan 2005 20:49:13 -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 9998) with SMTP; 27 Jan 2005 20:49:13 -0000 Message-ID: <41F953C8.6010300@dehora.net> Date: Thu, 27 Jan 2005 20:49: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: Re: PaceAttributesNamespace is *not* about syntax! References: <1f2ed5cd05012602474fc907a1@mail.gmail.com> <41F7A320.9020906@intertwingly.net> <8631b39ab59dd87f9ad947318c513654@bblfish.net> <3a0a09cffb909f5b93a3f6762f27f9e8@bblfish.net> <41F8FA79.4010906@dehora.net> <4306003c75fefe938dc569e28b7f88d0@bblfish.net> <41F920F5.8050400@dehora.net> <1f2ed5cd05012711385a4dd89e@mail.gmail.com> In-Reply-To: <1f2ed5cd05012711385a4dd89e@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 Danny Ayers wrote: > Yes and no - there is demand for this kind of thing, is the RSS 1.0 > community the same as the RDF community? There's a lot of additions > around there... Whatever, even with RSS 2.0 there's Easy News Topics > and all the stuff associated with media (enclosures + Yahoo's > extensions) as good examples. Is the RSS1.0 community relevant, given RSS1.1? I'm sincere in asking this. > My concern there is with extension development outside of the RDF > community. Without some uniform interpretation of the attributes > outside of the context of an Atom document, there's scope for unwanted > interactions. Assigning the things global names (URIs), even if they > aren't explicitly expressed in Atom documents seems a low cost > solution. > > >>>Does this help? >> >>Yes, but I think it can be dealt with as outlined above, unless I'm >>missing something. > > > Non-RDF extensions. As I've said, I'm not seeing the demand for uniform evaluation outside an RDF context. cheers Bill From owner-atom-syntax@mail.imc.org Thu Jan 27 16:14: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 QAA26620 for ; Thu, 27 Jan 2005 16:14: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 j0RL0kjv053836; Thu, 27 Jan 2005 13:00: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 j0RL0kCq053835; Thu, 27 Jan 2005 13:00: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 j0RL0jVp053828 for ; Thu, 27 Jan 2005 13:00:45 -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 j0RL0hdt021048 for ; Thu, 27 Jan 2005 14:00: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 <0IAZ008HEUD54O@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 27 Jan 2005 14:00:42 -0700 (MST) Received: from [192.168.1.4] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAZ00509UD0UK@mail.sun.net> for atom-syntax@imc.org; Thu, 27 Jan 2005 14:00:37 -0700 (MST) Date: Thu, 27 Jan 2005 13:00:35 -0800 From: Tim Bray Subject: Re: Mandatory method of specifying XHTML namespace? In-reply-to: <96ADD67E-70A3-11D9-B1FA-003065B8CF0E@iki.fi> To: Henri Sivonen Cc: Antone Roundy , atom-syntax@imc.org Message-id: <7D87085E-70A6-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: <2463D57C-7089-11D9-9325-003065EA6144@geckotribe.com> <96ADD67E-70A3-11D9-B1FA-003065B8CF0E@iki.fi> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 27, 2005, at 12:39 PM, Henri Sivonen wrote: >> which MUST declare the XHTML namespace, either as the default >> namespace or with a namespace prefix > > -1 Atom should not micro-manage how and on which elements namespace > declarations appear. > > Feed in the wild that declares the namespaces on root: > http://macsanomat.fi/atom He's got a point. It's a common (and many people say, good) idiom to declare all your namespaces on your root. I think all we can/should really say is that when type="XHTML", it is the responsibility of the feed generator to declare the XHTML namespace, because Atom won't do it for you. -Tim From owner-atom-syntax@mail.imc.org Thu Jan 27 16:22: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 QAA28668 for ; Thu, 27 Jan 2005 16:22: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 j0RLC28K054675; Thu, 27 Jan 2005 13:12: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 j0RLC2PU054674; Thu, 27 Jan 2005 13:12:02 -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 j0RLC12V054662 for ; Thu, 27 Jan 2005 13:12:01 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 27 Jan 2005 21:11:54 -0000 Received: from pD9E510B9.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.16.185) by mail.gmx.net (mp023) with SMTP; 27 Jan 2005 22:11:54 +0100 X-Authenticated: #1915285 Message-ID: <41F95916.4040308@gmx.de> Date: Thu, 27 Jan 2005 22:11:50 +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: Henri Sivonen , Antone Roundy , atom-syntax@imc.org Subject: Re: Mandatory method of specifying XHTML namespace? References: <2463D57C-7089-11D9-9325-003065EA6144@geckotribe.com> <96ADD67E-70A3-11D9-B1FA-003065B8CF0E@iki.fi> <7D87085E-70A6-11D9-9797-000A95A51C9E@sun.com> In-Reply-To: <7D87085E-70A6-11D9-9797-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: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > He's got a point. It's a common (and many people say, good) idiom to > declare all your namespaces on your root. I think all we can/should > really say is that when type="XHTML", it is the responsibility of the > feed generator to declare the XHTML namespace, because Atom won't do it > for you. -Tim +1 -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Thu Jan 27 16:22: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 QAA28710 for ; Thu, 27 Jan 2005 16:22: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 j0RLA9Xi054559; Thu, 27 Jan 2005 13: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 j0RLA9pC054558; Thu, 27 Jan 2005 13:10: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 j0RLA8wX054552 for ; Thu, 27 Jan 2005 13:10:08 -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 1CuGtw-0000BC-Ia for atom-syntax@imc.org; Thu, 27 Jan 2005 21:10:04 +0000 Message-ID: <41F958AE.8080709@franklinmint.fm> Date: Thu, 27 Jan 2005 16:10:06 -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: I-D ACTION:draft-ietf-atompub-format-05.txt References: <200501272053.PAA23410@ietf.org> In-Reply-To: <200501272053.PAA23410@ietf.org> 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 Hi all, Valid format-04 feeds are valid format-05 feeds. Known issues: * Order of appearance in Element Definitions * Cardinality requirement for atom:content appears in the wrong location. URIs: http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.txt and the not particularly useful http://atompub.org/2005/01/27/draft-ietf-atompub-format-05-from-4.diff.html Robert Sayre Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF. > > Title : The Atom Syndication Format > Author(s) : M. Nottingham, R. Sayre > Filename : draft-ietf-atompub-format-05.txt > Pages : 37 > Date : 2005-1-27 > >This document specifies Atom, an XML-based Web content and metadata > syndication format. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-05.txt > > From owner-atom-syntax@mail.imc.org Thu Jan 27 18:16: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 SAA10233 for ; Thu, 27 Jan 2005 18:16: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 j0RN5hR5062890; Thu, 27 Jan 2005 15:05: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 j0RN5hiH062889; Thu, 27 Jan 2005 15:05:43 -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 j0RN5g7O062882 for ; Thu, 27 Jan 2005 15:05:43 -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, 28 Jan 2005 12:06:22 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 28 Jan 2005 10:05:40 +1100 Subject: Re: PaceIconAndImage From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <200501271705.CLH91282@ms8.netsolmail.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 28/1/05 4:03 AM, "Bob Wyman" wrote: >> Also, why limit this to feed/head, and not entry? So that Atom >> feeds will be easily convertible to RSS 2.0? > > Converting *to* RSS 2.0 shouldn't be a goal or even a consideration > in any Atom related discussions. Only conversion *from* RSS 2.0 is > interesting. > > If Atom is guaranteed to be convertible both to and from RSS 2.0 > then Atom can never be more than RSS 2.0 and a great deal of the effort and > goodwill that has gone into Atom would be a complete waste of time. but we shouldn't get spiteful about it. If it doesn't matter either way on some point, why not allow compatibility? I'm saying it should be a consideration and possibly even an assumption, but remembering that if there is a good reason to go another route (and break compatibility) then that trumps the case. Lets not be incompatible for incompatibilities sake.! e. From owner-atom-syntax@mail.imc.org Thu Jan 27 18:16: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 SAA10251 for ; Thu, 27 Jan 2005 18: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 j0RN3CPe062642; Thu, 27 Jan 2005 15:03: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 j0RN3Coq062641; Thu, 27 Jan 2005 15:03: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 j0RN3AEO062584 for ; Thu, 27 Jan 2005 15:03: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); Fri, 28 Jan 2005 12:03:20 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 28 Jan 2005 10:02:37 +1100 Subject: Re: PaceIconAndImage 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 28/1/05 3:08 AM, "Antone Roundy" wrote: > Also, why limit this to feed/head, and not entry? So that Atom feeds > will be easily convertible to RSS 2.0? Certainly there are ways to add > images to entries in RSS 2.0, though not icons (as far as I'm aware), > but I don't think that's a big deal. RSS compatibility is one reason, as described in the rationale. Another is that we're not talking a generic image here, we're talking about some kind of special "badge" or branding image, which doesn't make sense for entries. You can still add whatever images (and other resources) you want to an entry with . Maybe we should rename the element to ? > Which brings me to PaceIconAndImage--the pace itself makes forbids > putting one of the attributes of Link Constructs in the elements > (@rel). Another of them (@href) is not accurately descriptive of what > it would be used for. Another of them (@title) doesn't seem very > useful for icon (unless for accessibility--do people more involved in > accessibility issues think that's needed--that it's going to be used to > say anything more than "xyz.com's icon"?) Is it really appropriate to > call this a Link Construct? I used a Link construct to keep word count down. Otherwise we'd need to define an extra four attributes which have exactly the same names as those in Link Constructs, which seemed like unnecessary wordage. It would really bloat the spec. Saying instead that it's a Link construct where one attribute is meaningless is much easier to not only write, but also to read. @rel - yeah, I wrestled with that myself too, but then remember that other elements place additional constraints on Link constructs elsewhere (eg. 4.2.2). Also, @rel is a MAY, so it's not like it's totally breaking the template. @href - what ever do you mean here? @title in certainly might be used for @alt text, the same way it is specced in RSS 2.0. That's why I left @title in. @title in could be used for @alt text if the icon is displayed someplace, or more likely simply ignored. The street will find a use for it, or not. e. From owner-atom-syntax@mail.imc.org Thu Jan 27 18:22: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 SAA11008 for ; Thu, 27 Jan 2005 18:22: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 j0RNCV7L063428; Thu, 27 Jan 2005 15:12: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 j0RNCVTv063427; Thu, 27 Jan 2005 15:12:31 -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 j0RNCTXi063418 for ; Thu, 27 Jan 2005 15:12:30 -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, 28 Jan 2005 12:13:09 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 28 Jan 2005 10:12:27 +1100 Subject: Re: Multiple content allowed? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <87d5vqyfcn.fsf@nwalsh.com> 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 j0RNCVXi063421 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 28/1/05 4:03 AM, "Norman Walsh" wrote: > Someone sent me this, noting that it was not valid according to the > grammar I posted. He thought it was legal according to the spec, > and I'm not sure. What say you? not legal. 5.12 "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. ... although I can't remember why we went zero or one. Maybe as a result of getting rid of the multipart/ madness. I like the idea of multiple elements as alternates (particularly with xml:lang or different @type) e. From owner-atom-syntax@mail.imc.org Thu Jan 27 18:26: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 SAA11163 for ; Thu, 27 Jan 2005 18: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 j0RNF7rD063610; Thu, 27 Jan 2005 15: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 j0RNF7gP063609; Thu, 27 Jan 2005 15:15:07 -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 j0RNF7pB063595 for ; Thu, 27 Jan 2005 15:15:07 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so273887rnz for ; Thu, 27 Jan 2005 15:15:01 -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=XwsFiszg2FjDMIh4ZvFrSU49I188kBz50iSDB3xipPhZ0Nl+vbi2CXmfaSQ2HMmWDflPVbBf1mQWLQDSuOICWCkij9vttGsWPdewYSwkGk6JFjmIuCzOMWA3i+axrC+XJM7QNq54umlFCVYztqr2dA7glIcOWA3INQOOwoWN7l0= Received: by 10.38.19.34 with SMTP id 34mr20227rns; Thu, 27 Jan 2005 15:15:01 -0800 (PST) Received: by 10.38.179.71 with HTTP; Thu, 27 Jan 2005 15:15:01 -0800 (PST) Message-ID: <1f2ed5cd050127151552eb2945@mail.gmail.com> Date: Fri, 28 Jan 2005 00:15:01 +0100 From: Danny Ayers Reply-To: Danny Ayers To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: PaceAttributesNamespace is *not* about syntax! Cc: Atom Syntax In-Reply-To: <41F953C8.6010300@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <1f2ed5cd05012602474fc907a1@mail.gmail.com> <41F7A320.9020906@intertwingly.net> <8631b39ab59dd87f9ad947318c513654@bblfish.net> <3a0a09cffb909f5b93a3f6762f27f9e8@bblfish.net> <41F8FA79.4010906@dehora.net> <4306003c75fefe938dc569e28b7f88d0@bblfish.net> <41F920F5.8050400@dehora.net> <1f2ed5cd05012711385a4dd89e@mail.gmail.com> <41F953C8.6010300@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0RNF7pB063603 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 27 Jan 2005 20:49:12 +0000, Bill de hÓra wrote: > > Danny Ayers wrote: > > > Yes and no - there is demand for this kind of thing, is the RSS 1.0 > > community the same as the RDF community? There's a lot of additions > > around there... Whatever, even with RSS 2.0 there's Easy News Topics > > and all the stuff associated with media (enclosures + Yahoo's > > extensions) as good examples. > > Is the RSS1.0 community relevant, given RSS1.1? I'm sincere in asking this. Dunno really. There are an awful lot of RSS 1.0 feeds out there - you've got one, I've got one. If rss-dev give the green light to 1.1, I'll probably changeover before long, though the extensions (FOAF, Geo) I've got in place aren't likely to change. > > My concern there is with extension development outside of the RDF > > community. Without some uniform interpretation of the attributes > > outside of the context of an Atom document, there's scope for unwanted > > interactions. Assigning the things global names (URIs), even if they > > aren't explicitly expressed in Atom documents seems a low cost > > solution. > > > > > >>>Does this help? > >> > >>Yes, but I think it can be dealt with as outlined above, unless I'm > >>missing something. > > > > > > Non-RDF extensions. > > As I've said, I'm not seeing the demand for uniform evaluation outside > an RDF context. Outside of the [insert Brayism about architects], demand for uniformity is generally thin on the ground around syndication (s ring a bell?). But that doesn't reduce its benefits, usually uniformity leads to a net cost reduction, don't you reckon? Standards and all that? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Jan 27 18:52: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 SAA12554 for ; Thu, 27 Jan 2005 18:52: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 j0RNcn6W066004; Thu, 27 Jan 2005 15:38: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 j0RNcnu1066003; Thu, 27 Jan 2005 15:38: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 j0RNclqw065996 for ; Thu, 27 Jan 2005 15:38: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, 28 Jan 2005 12:39:27 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 28 Jan 2005 10:38:45 +1100 Subject: Re: Mandatory method of specifying XHTML namespace? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <96ADD67E-70A3-11D9-B1FA-003065B8CF0E@iki.fi> 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 28/1/05 7:39 AM, "Henri Sivonen" wrote: >> If the value of "type" is "XHTML", the content of the Text construct >> MUST be a single xhtml:div element > > -1 gratuitous element cruft. The text construct element itself serves > as a container. but atom:title != xhtml:title also, are there such things as xhtml:copyright, xhtml:info, or xhtml:summary? >> which MUST declare the XHTML namespace, either as the default >> namespace or with a namespace prefix > > -1 Atom should not micro-manage how and on which elements namespace > declarations appear. > > Feed in the wild that declares the namespaces on root: Good point. The declaration of the namespace 'xhtml' can occur elsewhere, and if on the root then it cuts down on needless repetition. e. From owner-atom-syntax@mail.imc.org Thu Jan 27 19:22: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 TAA15070 for ; Thu, 27 Jan 2005 19:22: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 j0RNxtbE068529; Thu, 27 Jan 2005 15:59: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 j0RNxt31068524; Thu, 27 Jan 2005 15:59:55 -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 j0RNxr0N068491 for ; Thu, 27 Jan 2005 15:59:54 -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, 28 Jan 2005 13:00:33 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 28 Jan 2005 10:59:51 +1100 Subject: Re: PaceIconAndImage 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 28/1/05 10:02 AM, "Eric Scheid" wrote: > I used a Link construct to keep word count down and now with -05 published there is no generic Link Construct. I'll update the pace with all the necessary extra wordage and bloat. e. From owner-atom-syntax@mail.imc.org Thu Jan 27 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 WAA28052 for ; Thu, 27 Jan 2005 22: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 j0S2wl7Q082999; Thu, 27 Jan 2005 18:58: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 j0S2wlh5082998; Thu, 27 Jan 2005 18:58:47 -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 j0S2wkDo082992 for ; Thu, 27 Jan 2005 18:58:46 -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 1760A4EED3; Thu, 27 Jan 2005 21:58:40 -0500 (EST) Message-Id: <6.0.0.20.2.20050128115641.0716ea80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 28 Jan 2005 11:57:51 +0900 To: Tim Bray , Henri Sivonen From: Martin Duerst Subject: Re: Mandatory method of specifying XHTML namespace? Cc: Antone Roundy , atom-syntax@imc.org In-Reply-To: <7D87085E-70A6-11D9-9797-000A95A51C9E@sun.com> References: <2463D57C-7089-11D9-9325-003065EA6144@geckotribe.com> <96ADD67E-70A3-11D9-B1FA-003065B8CF0E@iki.fi> <7D87085E-70A6-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 06:00 05/01/28, Tim Bray wrote: > >On Jan 27, 2005, at 12:39 PM, Henri Sivonen wrote: > >>> which MUST declare the XHTML namespace, either as the default namespace or with a namespace prefix >> >> -1 Atom should not micro-manage how and on which elements namespace declarations appear. >> >> Feed in the wild that declares the namespaces on root: >> http://macsanomat.fi/atom > >He's got a point. It's a common (and many people say, good) idiom to declare all your namespaces on your root. I think all we can/should really say is that when type="XHTML", it is the responsibility of the feed generator to declare the XHTML namespace, because Atom won't do it for you. -Tim +1 on this, -1 on any additional suggestions in this thread. We are using XML with namespaces, and we shouldn't mess around with that. Regards, Martin. From owner-atom-syntax@mail.imc.org Fri Jan 28 00:55: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 AAA09862 for ; Fri, 28 Jan 2005 00:55: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 j0S5cqto093518; Thu, 27 Jan 2005 21: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 j0S5cqEJ093517; Thu, 27 Jan 2005 21:38:52 -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 j0S5cpGX093497 for ; Thu, 27 Jan 2005 21:38:51 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-12.adsl-net.finnetcom.net ([217.140.228.12]:54275 "EHLO [217.140.228.12]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228681AbVA1Fif (ORCPT ); Fri, 28 Jan 2005 07:38:35 +0200 In-Reply-To: <4F53DB25-70A2-11D9-9325-003065EA6144@geckotribe.com> References: <4F53DB25-70A2-11D9-9325-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v619) 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: PaceXhtmlNamespaceDiv posted Date: Fri, 28 Jan 2005 07:38:30 +0200 To: Antone Roundy X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 27, 2005, at 22:30, Antone Roundy wrote: > I'm not in favor of mandating restrictions, because there are probably > legitimate uses for anything we might try to protect people against. The namespace div places restrictions on where namespace declarations appear and, therefore, limits the legitimate use of serializers that take care of namespace declarations. -1 for the pace, still. -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Fri Jan 28 02:32: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 CAA29579 for ; Fri, 28 Jan 2005 02:32: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 j0S5kDBE093982; Thu, 27 Jan 2005 21: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 j0S5kDJK093981; Thu, 27 Jan 2005 21:46:13 -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 j0S5kCV8093971 for ; Thu, 27 Jan 2005 21:46: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 (rwcrmhc12) with SMTP id <20050128054607014003be6oe>; Fri, 28 Jan 2005 05:46:07 +0000 Date: Thu, 27 Jan 2005 22:46:06 -0700 Subject: Re: PaceXhtmlNamespaceDiv 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: 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 10:38 PM, Henri Sivonen wrote: > On Jan 27, 2005, at 22:30, Antone Roundy wrote: > >> I'm not in favor of mandating restrictions, because there are >> probably legitimate uses for anything we might try to protect people >> against. > > The namespace div places restrictions on where namespace declarations > appear and, therefore, limits the legitimate use of serializers that > take care of namespace declarations. > > -1 for the pace, still. > Okay, this one's obviously dead. Let's just make sure we have examples that make how all these things work clear. From owner-atom-syntax@mail.imc.org Fri Jan 28 02:47: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 CAA01823 for ; Fri, 28 Jan 2005 02:47: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 j0S7WFXR027933; Thu, 27 Jan 2005 23:32: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 j0S7WFkr027932; Thu, 27 Jan 2005 23:32:15 -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 j0S7WEDq027722 for ; Thu, 27 Jan 2005 23:32:14 -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, 28 Jan 2005 20:00:22 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 28 Jan 2005 17:59:40 +1100 Subject: Re: Mandatory method of specifying XHTML namespace? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <95343FC2-70F1-11D9-B1FA-003065B8CF0E@iki.fi> 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 28/1/05 4:58 PM, "Henri Sivonen" wrote: > Copyright 2005 John Doe, all rights > reserved > (assuming 'a' to be bound to the Atom namespace and 'h' to the XHTML > namespace) is less crufty than >
xmlns='http://www.w3.org/1999/xhtml'>Copyright 2005 John Doe, all > rights reserved
 and this is somewhere in the middle... Copyright 2005 John Doe, all rights reserved once you have more than just one set of tags like in there. e. From owner-atom-syntax@mail.imc.org Fri Jan 28 03:56: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 DAA08757 for ; Fri, 28 Jan 2005 03:56: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 j0S7ZRfp029124; Thu, 27 Jan 2005 23:35: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 j0S7ZRsf029122; Thu, 27 Jan 2005 23:35:27 -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 j0S7ZQif029029 for ; Thu, 27 Jan 2005 23:35:26 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-12.adsl-net.finnetcom.net ([217.140.228.12]:54285 "EHLO [217.140.228.12]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228694AbVA1GGs (ORCPT ); Fri, 28 Jan 2005 08:06:48 +0200 In-Reply-To: <41F95168.7050908@franklinmint.fm> References: <41F60A5C.1060308@annevankesteren.nl> <41F6DE44.8020906@franklinmint.fm> <41F94F43.7010809@annevankesteren.nl> <41F95168.7050908@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) 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: Issues with draft-ietf-atompub-format-04 Date: Fri, 28 Jan 2005 08:06:40 +0200 To: Robert Sayre X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 27, 2005, at 22:39, Robert Sayre wrote: > Anne van Kesteren wrote: >> >> So I can not include MathML in the TITLE of my weblog? I do not see >> why this restriction is necessary. > > Nope. Can any aggregator display it? I expect Gecko-based aggregators to support MathML eventually. After all, once you support XHTML content in a Gecko-based aggregator in a non-bogotic way (XML DOM to XML DOM copy with platupus filtering), you get MathML for free. -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Fri Jan 28 03:56: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 DAA08797 for ; Fri, 28 Jan 2005 03:56: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 j0S7cPIq030172; Thu, 27 Jan 2005 23: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 j0S7cPBB030171; Thu, 27 Jan 2005 23:38: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 j0S7cPHu030146 for ; Thu, 27 Jan 2005 23:38:25 -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 1CuPYC-0004VF-5v; Fri, 28 Jan 2005 06:24:12 +0000 Message-ID: <41F9DA8C.50308@franklinmint.fm> Date: Fri, 28 Jan 2005 01:24:12 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henri Sivonen CC: atom-syntax@imc.org, Anne van Kesteren Subject: Re: Issues with draft-ietf-atompub-format-04 References: <41F60A5C.1060308@annevankesteren.nl> <41F6DE44.8020906@franklinmint.fm> <41F94F43.7010809@annevankesteren.nl> <41F95168.7050908@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 Henri Sivonen wrote: > On Jan 27, 2005, at 22:39, Robert Sayre wrote: > >> Anne van Kesteren wrote: >> >>> >>> So I can not include MathML in the TITLE of my weblog? I do not see >>> why this restriction is necessary. >> >> >> Nope. Can any aggregator display it? > > > I expect Gecko-based aggregators to support MathML eventually. After > all, once you support XHTML content in a Gecko-based aggregator in a > non-bogotic way (XML DOM to XML DOM copy with platupus filtering), you > get MathML for free. We are not here to standardize "eventually." This discussion is a waste of time. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Jan 28 03:56: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 DAA08826 for ; Fri, 28 Jan 2005 03:56: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 j0S7ZRUU029123; Thu, 27 Jan 2005 23:35: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 j0S7ZRH0029120; Thu, 27 Jan 2005 23:35:27 -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 j0S7ZQie029029 for ; Thu, 27 Jan 2005 23:35:26 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-12.adsl-net.finnetcom.net ([217.140.228.12]:54280 "EHLO [217.140.228.12]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228758AbVA1F6M (ORCPT ); Fri, 28 Jan 2005 07:58:12 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <95343FC2-70F1-11D9-B1FA-003065B8CF0E@iki.fi> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henri Sivonen Subject: Re: Mandatory method of specifying XHTML namespace? Date: Fri, 28 Jan 2005 07:58:07 +0200 To: Eric Scheid X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 28, 2005, at 01:38, Eric Scheid wrote: > On 28/1/05 7:39 AM, "Henri Sivonen" wrote: > >>> If the value of "type" is "XHTML", the content of the Text construct >>> MUST be a single xhtml:div element >> >> -1 gratuitous element cruft. The text construct element itself serves >> as a container. > > but atom:title != xhtml:title > > also, are there such things as xhtml:copyright, xhtml:info, or > xhtml:summary? No, but that is not the point. The *Atom* Text constructs work as containers. The div is just cruft. IMO, Copyright 2005 John Doe, all rights reserved (assuming 'a' to be bound to the Atom namespace and 'h' to the XHTML namespace) is less crufty than
Copyright 2005 John Doe, all rights reserved
 . Even if you wanted to declare the XHTML namespace on the spot, you could put the declaration on the Atom Text construct. Any feed reader using namespace-aware XML tools properly will have no trouble dealing with the less crufty versions. -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Fri Jan 28 09: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 JAA02606 for ; Fri, 28 Jan 2005 09: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 j0SDq7Qo049645; Fri, 28 Jan 2005 05:52: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 j0SDq7Ih049644; Fri, 28 Jan 2005 05:52:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-1.hut.fi (smtp-1.hut.fi [130.233.228.91]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SDq5kA049588 for ; Fri, 28 Jan 2005 05:52:06 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from localhost (putosiko.hut.fi [130.233.228.114]) by smtp-1.hut.fi (8.12.10/8.12.10) with ESMTP id j0SAWkUn030446; Fri, 28 Jan 2005 12:32:46 +0200 Received: from smtp-1.hut.fi ([130.233.228.91]) by localhost (putosiko.hut.fi [130.233.228.114]) (amavisd-new, port 10024) with LMTP id 16793-06-10; Fri, 28 Jan 2005 12:32:46 +0200 (EET) Received: from [130.233.248.108] (percivale.hut.fi [130.233.248.108]) by smtp-1.hut.fi (8.12.10/8.12.10) with ESMTP id j0SAUK1s029932; Fri, 28 Jan 2005 12:30:22 +0200 Message-ID: <41FA143C.2070709@iki.fi> Date: Fri, 28 Jan 2005 12:30:20 +0200 From: Henri Sivonen User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: Mandatory method of specifying XHTML namespace? References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on putosiko.hut.fi X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at putosiko.hut.fi Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: > and this is somewhere in the middle... > > > Copyright 2005 John Doe, all rights reserved > > > once you have more than just one set of tags like in there. The em element does not inherit the namespace of he div. You could have bound to one namespace, 'h' to another and still have a third namespace as the default namespace. It would be inapropriate to forbit declaring the same namespace in multiple ways, but the div is still cruft and unnecessary for declaring namespaces, so I think the div shouldn't be required. -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Fri Jan 28 09:29: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 JAA04235 for ; Fri, 28 Jan 2005 09:29: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 j0SEGtgd055252; Fri, 28 Jan 2005 06:16: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 j0SEGkHM055234; Fri, 28 Jan 2005 06:16:46 -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 ([64.233.170.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SEGSXF055152 for ; Fri, 28 Jan 2005 06:16:44 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so316321rnz for ; Fri, 28 Jan 2005 06:14: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=X0RE5NeINDiW40CmVMdp2NnC9qHmmWZRH3aRr19mzD8ouodVcybVTniUCTLYxx6oNeOplCGHvt8HNal6/MALFOEhUcLSPy34cknWxtC535nPAvAEvsobv4OIWCAmDMuSblqM3c9s2fZOFU22QoyAbTAnxkM0WzkDfWK43gvg3vo= Received: by 10.38.179.17 with SMTP id b17mr28575rnf; Fri, 28 Jan 2005 06:14:58 -0800 (PST) Received: by 10.38.179.71 with HTTP; Fri, 28 Jan 2005 06:14:58 -0800 (PST) Message-ID: <1f2ed5cd05012806146e98a15d@mail.gmail.com> Date: Fri, 28 Jan 2005 15:14:58 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Robert Sayre Subject: Re: I-D ACTION:draft-ietf-atompub-format-05.txt Cc: atom-syntax@imc.org In-Reply-To: <41F958AE.8080709@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200501272053.PAA23410@ietf.org> <41F958AE.8080709@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 27 Jan 2005 16:10:06 -0500, Robert Sayre wrote: > http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html > http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.txt Thanks Robert. The Relax NG snippets make a *huge* difference to the clarity. (Thanks Norm!). > and the not particularly useful > > http://atompub.org/2005/01/27/draft-ietf-atompub-format-05-from-4.diff.html Aw, but it's much prettier... Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Jan 28 09:33: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 JAA04442 for ; Fri, 28 Jan 2005 09:33: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 j0SEIiQT055456; Fri, 28 Jan 2005 06:18: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 j0SEIiZt055455; Fri, 28 Jan 2005 06:18: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.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SEIDkH055304 for ; Fri, 28 Jan 2005 06:18:42 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so316495rnz for ; Fri, 28 Jan 2005 06:17: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=X0RE5NeINDiW40CmVMdp2NnC9qHmmWZRH3aRr19mzD8ouodVcybVTniUCTLYxx6oNeOplCGHvt8HNal6/MALFOEhUcLSPy34cknWxtC535nPAvAEvsobv4OIWCAmDMuSblqM3c9s2fZOFU22QoyAbTAnxkM0WzkDfWK43gvg3vo= Received: by 10.38.179.17 with SMTP id b17mr28575rnf; Fri, 28 Jan 2005 06:14:58 -0800 (PST) Received: by 10.38.179.71 with HTTP; Fri, 28 Jan 2005 06:14:58 -0800 (PST) Message-ID: <1f2ed5cd05012806146e98a15d@mail.gmail.com> Date: Fri, 28 Jan 2005 15:14:58 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Robert Sayre Subject: Re: I-D ACTION:draft-ietf-atompub-format-05.txt Cc: atom-syntax@imc.org In-Reply-To: <41F958AE.8080709@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200501272053.PAA23410@ietf.org> <41F958AE.8080709@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 27 Jan 2005 16:10:06 -0500, Robert Sayre wrote: > http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html > http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.txt Thanks Robert. The Relax NG snippets make a *huge* difference to the clarity. (Thanks Norm!). > and the not particularly useful > > http://atompub.org/2005/01/27/draft-ietf-atompub-format-05-from-4.diff.html Aw, but it's much prettier... Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Jan 28 09:48: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 JAA05208 for ; Fri, 28 Jan 2005 09:48: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 j0SEYYKc056642; Fri, 28 Jan 2005 06:34: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 j0SEYYSn056640; Fri, 28 Jan 2005 06:34:34 -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 j0SEYYBX056626 for ; Fri, 28 Jan 2005 06:34:34 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 95424 invoked by uid 17064); 28 Jan 2005 14:34:24 -0000 Received: from unknown (HELO [192.168.0.5]) ([83.112.104.28]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 28 Jan 2005 14:34:24 -0000 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <1f2ed5cd05012806146e98a15d@mail.gmail.com> References: <200501272053.PAA23410@ietf.org> <41F958AE.8080709@franklinmint.fm> <1f2ed5cd05012806146e98a15d@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: I-D ACTION:draft-ietf-atompub-format-05.txt Date: Fri, 28 Jan 2005 15:34:19 +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 28 Jan 2005, at 15:14, Danny Ayers wrote: > > On Thu, 27 Jan 2005 16:10:06 -0500, Robert Sayre > wrote: > >> http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html >> http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.txt > > Thanks Robert. The Relax NG snippets make a *huge* difference to the > clarity. (Thanks Norm!). Yes. A real pleasure to read now :-) From owner-atom-syntax@mail.imc.org Fri Jan 28 13: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 NAA26653 for ; Fri, 28 Jan 2005 13:23: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 j0SI3uNU072996; Fri, 28 Jan 2005 10:03: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 j0SI3um6072995; Fri, 28 Jan 2005 10:03:56 -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 j0SI3pgW072979 for ; Fri, 28 Jan 2005 10:03:51 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so705667rne for ; Fri, 28 Jan 2005 10:03: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:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=IAFaxVmZqzV85k0WK6k0M2h1nKCN2Y3Ais4SBs9sK3QGIItdNGd0eAyG+Azh/CilW4HR2eSeasQ+v6cwerBkLfF3vVO7BlRhg2DbX/jxZg5F+IwHy7UJxklwYfevUVmommq+ZyZ5Mu0bWtFQlXmFS067bNb6/3I8C62QMQCB/CQ= Received: by 10.38.59.28 with SMTP id h28mr107701rna; Fri, 28 Jan 2005 10:03:44 -0800 (PST) Received: by 10.38.151.21 with HTTP; Fri, 28 Jan 2005 10:03:34 -0800 (PST) Message-ID: <3f1451f505012810038eab9d7@mail.gmail.com> Date: Fri, 28 Jan 2005 13:03:34 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Antone Roundy Subject: Re: PaceXhtmlNamespaceDiv posted Cc: atom-syntax@imc.org In-Reply-To: <4F53DB25-70A2-11D9-9325-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41F944E4.9010101@annevankesteren.nl> <4F53DB25-70A2-11D9-9325-003065EA6144@geckotribe.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 27 Jan 2005 13:30:40 -0700, Antone Roundy wrote: > As far as the question of CSS and/or elements/tags everywhere, I'd > think that would be a matter for the security considerations section > (protecting against the Raging Platypus, for example). Whatever > restrictions we may pronounce, consumers will still have to include > code to protect against abuses. And these issues apply equally to HTML > as to XHTML. > > I'm not in favor of mandating restrictions, because there are probably > legitimate uses for anything we might try to protect people against. +1, and the same goes for 'id', just leave it as an item for the security considerations. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Fri Jan 28 13:32: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 NAA27325 for ; Fri, 28 Jan 2005 13:32: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 j0SIM9qu074179; Fri, 28 Jan 2005 10:22: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 j0SIM9KQ074178; Fri, 28 Jan 2005 10:22:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [69.20.61.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SIM8VW074168 for ; Fri, 28 Jan 2005 10:22:08 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [172.18.40.150] (nat-147-1.oreilly.com [209.204.147.1]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.10) with ESMTP id j0SILvpP016913; Fri, 28 Jan 2005 13:22:00 -0500 Message-ID: <41FA82C6.6080601@intertwingly.net> Date: Fri, 28 Jan 2005 13:21:58 -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: PaceXhtmlNamespaceDiv posted References: In-Reply-To: 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 Antone Roundy wrote: > > On Thursday, January 27, 2005, at 10:38 PM, Henri Sivonen wrote: > >> On Jan 27, 2005, at 22:30, Antone Roundy wrote: >> >>> I'm not in favor of mandating restrictions, because there are >>> probably legitimate uses for anything we might try to protect people >>> against. >> >> The namespace div places restrictions on where namespace declarations >> appear and, therefore, limits the legitimate use of serializers that >> take care of namespace declarations. >> >> -1 for the pace, still. >> > Okay, this one's obviously dead. Let's just make sure we have examples > that make how all these things work clear. I also don't like the restriction on where namespace declarations must be placed, but overall, I believe that the pace is a good idea. Consumers don't want full web pages (complete with html head and titles) as summaries, they want something that they can *insert* into a web page. Requiring a div element addresses a number of needs - it makes it easier to get the namespace right, and it succinctly provides a rather good hint as to what child elements are valid. On content, the situation is a bit different - the content need not be displayable, after all. I would be OK with either keeping the definition of type='XHTML' consistent (there are other types available, after all) or requiring a summary element to be present if the first child element of atom:content with type='XHTML' is not an xhtml:div. - Sam Ruby From owner-atom-syntax@mail.imc.org Fri Jan 28 13:52: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 NAA29316 for ; Fri, 28 Jan 2005 13:52: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 j0SIetdi076874; Fri, 28 Jan 2005 10:40: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 j0SIetI9076873; Fri, 28 Jan 2005 10:40:55 -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 j0SIerL8076849 for ; Fri, 28 Jan 2005 10:40:54 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 28 Jan 2005 18:40:39 -0000 Received: from p50825E9D.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.94.157) by mail.gmx.net (mp022) with SMTP; 28 Jan 2005 19:40:39 +0100 X-Authenticated: #1915285 Message-ID: <41FA8725.6010600@gmx.de> Date: Fri, 28 Jan 2005 19:40:37 +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: Antone Roundy , atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv posted References: <41FA82C6.6080601@intertwingly.net> In-Reply-To: <41FA82C6.6080601@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: > I also don't like the restriction on where namespace declarations must > be placed, but overall, I believe that the pace is a good idea. > > Consumers don't want full web pages (complete with html head and titles) > as summaries, they want something that they can *insert* into a web > page. Requiring a div element addresses a number of needs - it makes it > easier to get the namespace right, and it succinctly provides a rather > good hint as to what child elements are valid. That's what the spec already says, doesn't it? -> > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Fri Jan 28 14:11: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 OAA02562 for ; Fri, 28 Jan 2005 14: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 j0SJ0H8h079249; Fri, 28 Jan 2005 11:00: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 j0SJ0Hje079248; Fri, 28 Jan 2005 11:00:17 -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 ([161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SJ0GKx079193 for ; Fri, 28 Jan 2005 11:00: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 j0SIwVNh023905; Fri, 28 Jan 2005 18:58:35 GMT In-Reply-To: <41FA82C6.6080601@intertwingly.net> References: <41FA82C6.6080601@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9AACF762-715E-11D9-9153-000A95DC3D90@mac.com> Content-Transfer-Encoding: 7bit Cc: Antone Roundy , atom-syntax@imc.org From: Graham Subject: Re: PaceXhtmlNamespaceDiv posted Date: Fri, 28 Jan 2005 18:58:32 +0000 To: Sam Ruby X-Mailer: Apple Mail (2.619) 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 28 Jan 2005, at 6:21 pm, Sam Ruby wrote: > I also don't like the restriction on where namespace declarations must > be placed, but overall, I believe that the pace is a good idea. Yes. > and it succinctly provides a rather > good hint as to what child elements are valid. Yes. > I would be OK with either keeping the definition of type='XHTML' > consistent (there are other types available, > after all) Yes. > or requiring a summary element to be present if the first > child element of atom:content with type='XHTML' is not an xhtml:div. Ew. Graham From owner-atom-syntax@mail.imc.org Fri Jan 28 14:33: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 OAA04919 for ; Fri, 28 Jan 2005 14:33: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 j0SJGCR0080858; Fri, 28 Jan 2005 11: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 j0SJGCgr080857; Fri, 28 Jan 2005 11:16:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [69.20.61.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SJGBNU080850 for ; Fri, 28 Jan 2005 11:16:11 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [172.18.40.150] (nat-147-1.oreilly.com [209.204.147.1]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.10) with ESMTP id j0SJFs9I023536; Fri, 28 Jan 2005 14:15:56 -0500 Message-ID: <41FA8F6C.1080805@intertwingly.net> Date: Fri, 28 Jan 2005 14:15:56 -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 posted References: <41FA82C6.6080601@intertwingly.net> <41FA8725.6010600@gmx.de> In-Reply-To: <41FA8725.6010600@gmx.de> 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 Julian Reschke wrote: > Sam Ruby wrote: > >> I also don't like the restriction on where namespace declarations must >> be placed, but overall, I believe that the pace is a good idea. >> >> Consumers don't want full web pages (complete with html head and titles) >> as summaries, they want something that they can *insert* into a web >> page. Requiring a div element addresses a number of needs - it makes it >> easier to get the namespace right, and it succinctly provides a rather >> good hint as to what child elements are valid. > > That's what the spec already says, doesn't it? -> > 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 Fri Jan 28 14:36: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 OAA05314 for ; Fri, 28 Jan 2005 14:36: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 j0SJMknH081812; Fri, 28 Jan 2005 11: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 j0SJMkfT081811; Fri, 28 Jan 2005 11:22:46 -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 j0SJMivr081724 for ; Fri, 28 Jan 2005 11:22:44 -0800 (PST) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so913558wri for ; Fri, 28 Jan 2005 11:22: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=Mz1fgKPeLJe5KoygKh/kssqghZHdBYbZ7IsWRvBTBnPkIzzoVq8tSRq5+E44cUkFWbzQhNOTlIhWIXybpbp1IV3WvYJGjip3I/Uq/oCtke5Zi3N6i578CqYrrL3P/G1LR3W8afWIjAVGo5OV1Nj+nXsL44kfNa95T+NhpuBLSkk= Received: by 10.54.26.7 with SMTP id 7mr49952wrz; Fri, 28 Jan 2005 11:22:14 -0800 (PST) Received: by 10.54.18.2 with HTTP; Fri, 28 Jan 2005 11:22:14 -0800 (PST) Message-ID: <540e373205012811227889a7dd@mail.gmail.com> Date: Fri, 28 Jan 2005 13:22:14 -0600 From: "Roger B." Reply-To: "Roger B." To: Sam Ruby Subject: Re: PaceXhtmlNamespaceDiv posted Cc: Julian Reschke , atom-syntax@imc.org In-Reply-To: <41FA8F6C.1080805@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41FA82C6.6080601@intertwingly.net> <41FA8725.6010600@gmx.de> <41FA8F6C.1080805@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > 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. +1 -- Roger Benningfield From owner-atom-syntax@mail.imc.org Fri Jan 28 14:49: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 OAA06544 for ; Fri, 28 Jan 2005 14:49: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 j0SJbE8W083543; Fri, 28 Jan 2005 11:37: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 j0SJbEWY083542; Fri, 28 Jan 2005 11:37: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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SJbE6I083536 for ; Fri, 28 Jan 2005 11:37:14 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so736490rne for ; Fri, 28 Jan 2005 11:37:14 -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=VNgt19ueF8mMNt3Kn0BNBLkvr7NroWUGjuC+nYnuWk548ZnDU/e58SpAQLzbw5rs+o+TNLaFqVI8zWGGLvvN8iQrWKaLlpjrHZ+CxCxZnaMziHDOMP/4P8LqGiAZfX3YF1TCRCBJvSWPusxAzrZu6gXprAOZatsja4ga1VFKa7M= Received: by 10.38.59.28 with SMTP id h28mr165829rna; Fri, 28 Jan 2005 11:37:13 -0800 (PST) Received: by 10.38.151.21 with HTTP; Fri, 28 Jan 2005 11:37:13 -0800 (PST) Message-ID: <3f1451f50501281137226f64f4@mail.gmail.com> Date: Fri, 28 Jan 2005 14:37:13 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Atom Syntax Subject: PaceFormatSecurity 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 looked at format-05 and found that the security section is still pretty anemic. Here is my stab at fleshing out that section: http://www.intertwingly.net/wiki/pie/PaceFormatSecurity: =================================== == Abstract == Fill out the security section of the format spec. == Status == Open Author: JoeGregorio Much of the material presented here has been covered by Mark Pilgrim in his post on consuming RSS Safely: http://diveintomark.org/archives/2003/06/12/how_to_consume_rss_safely == Rationale == Security is more than just encryption and signatures. == Proposal == Add the following text to ""10 Security Considerations"" {{{ 10.1 HTML and XHTML Text Constructs Text Constructs allow the delivery of HTML and XHTML into a client application which may then display that (X)HTML. Because that (X)HTML may be displayed either in a web browser or via an embedded web browser in a desktop application, many security concerns will arise since that (X)HTML may be displayed in a different context from which it was originally served. A consuming application needs to be very careful about the context in which that (X)HTML is displayed to avoid cross site scripting attacks and other forms information leakage. An aggregator will certainly display the (X)HTML of a Text Construct in a different context than if an HTML page had been loaded from the same server as that had served up the Atom feed. That is, the (X)HTML may be displayed through a different web site if is a web based aggregator, or as a local file if the aggregator is a desktop kind. There are also aggregators that serve files up via a web server that run off the desktop. Because of these differening contexts there is an opening for cross site scripting attacks or other forms of information leakage. 10.1.1 HTML Elements The following elements are consider 'unsafe' in that they open clients to one or more types of attack. Every client should consider carefully their handling of each of them when processing incoming (X)HTML in Text Constructs. 10.1.1.1 IMG Element The image element may pose a threat by inadvertely leaking information. That is, a hostile feed may include a Text Construct with a "web bug", a 1x1 pixel image that gets loaded invisibly to the user. The request itself and the referral information the client application provides may leak information about who is reading the content and when the content was read. 10.1.1.2 SCRIPT Element All SCRIPT elements should be stripped from Text Constructs or all native scripting support of the (X)HTML display engine should be disabled. Allowing any script to run would allow cross site scripting attacks. 10.1.1.3 EMBED and OBJECT Elements All EMBED and OBJECT elements should be stripped from Text Constructs. The danger here is loading up an an embedded object in an unsafe context. For example an ActiveX control could be run in local context considered safe while it would not normally be loaded from it's origin site which was considered unsafe. ActiveX is not the only technology to suffer from this problem, SVG allows JavaScript to be embedded in it, and if displayed in an EMBEB or OBJECT element could open the client up to a cross site scripting attack. 10.1.1.4 FRAME, FRAMESET, and IFRAME Elements The FRAME, FRAMESET, and IFRAME Elements allow loading (X)HTML in from a different context. 10.1.1.5 META Elements Some (X)HTML processors are very loose in what they will accept for HTML, including processing elements that would normally appear in the HEAD of a document even when they are present in the BODY. Such a loose (X)HTML processor may process a META element which could redirect the HTML processor to load another page. 10.1.1.6 LINK Elements The same loose processing that may inadvertenly pick up META elements can also pick up LINK elements which can cause CSS Stylesheets to be loaded. Please see Section 10.1.2 on the potential problems with CSS. 10.1.2 CSS The processing of CSS (Cascading Stylesheets) also has security concers. CSS allows the loading of images, which has all the same concerns as the IMG element [Section 10.1.1.1]. In addition CSS allows HTML elements to be hidden or positioned absolutely. If a group of syndication feeds are processed and displayed in a single HTML page then some errant or malicious CSS could ovelay the entire page with a single large image repeated endlessly, thus rendering the entire page unusable. Some browsers also support proprietary extensions which allow the execution of scripts within CSS. For these reasons clients should strongly consider stripping all STYLE elements from the (X)HTML and also remove all STYLE Attributes in the (X)HTML elements themselves. 10.1.3 URIs Since any consumer of an Atom feed will be processing URIs, the security concerns for handling URIs must also be taken into account. See Section 7 of RFC 3986. 10.1.4 IRIs Since any consumer of an Atom feed will be processing IRIs, the security concerns for handling IRIs must also be taken into account. See Section 8 of RFC 3987. }}} == Impacts == == Notes == ---- CategoryProposals Thanks, -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Fri Jan 28 15:23: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 PAA09968 for ; Fri, 28 Jan 2005 15:23: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 j0SKAkQ6087024; Fri, 28 Jan 2005 12:10: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 j0SKAkZB087023; Fri, 28 Jan 2005 12:10:46 -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 j0SKAjMk086991 for ; Fri, 28 Jan 2005 12:10: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 j0SK9SWG009347; Fri, 28 Jan 2005 20:09:34 GMT In-Reply-To: <3f1451f50501281137226f64f4@mail.gmail.com> References: <3f1451f50501281137226f64f4@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--213250780; protocol="application/pkcs7-signature" Message-Id: <9c7695aad7004a39f148af7e39fd83fc@mac.com> Cc: Atom Syntax From: Graham Subject: Re: PaceFormatSecurity Date: Fri, 28 Jan 2005 20:09:27 +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-1--213250780 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I don't like stuff like: "All SCRIPT elements should be stripped from Text Constructs or all native scripting support of the (X)HTML display engine should be disabled." I don't think you need to should do any more than outline the threat model from each tech. Proscribing how to deal with it is not on, especially when they're this drastic. Graham --Apple-Mail-1--213250780 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 9w0BCQUxDxcNMDUwMTI4MjAwOTI4WjAjBgkqhkiG9w0BCQQxFgQUSU6TNM3pOsk0pQkg1rl0vMQj PzAweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAsWymRz6at3Krqa5idfkwzKHv hX31rymnghbXLwzqrS73tZVKJgi/eRqbRk+iczx4q5R7y8mYa2BcDru//dT4gIi3ar7rnXWbQQbX XeGUWLPYs65Og2e9I2qiRKc0O50fV4sHHyZ/3+SPRId4LAJ4ggHMeg2mI6u1p1VS/hUZOUXYYaHq uJDD6gOviyaZfjPA7VC6g47aWOzFEst3muid51Gxq9Ux3w99y15Q5n4gkE4fCAC+Nw93/8FZhfNR /8IZEo8Gw0zkyNyeviWHPzmbBxndaqNPZ8SXhCFnJlffF6u1iZlJSkN+im1eznRPDP3sqLLoycMA ORiCn8pKyjMaegAAAAAAAA== --Apple-Mail-1--213250780-- From owner-atom-syntax@mail.imc.org Fri Jan 28 16: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 QAA13111 for ; Fri, 28 Jan 2005 16: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 j0SKtGdU090987; Fri, 28 Jan 2005 12:55: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 j0SKtGol090986; Fri, 28 Jan 2005 12:55:16 -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 j0SKtF7N090976 for ; Fri, 28 Jan 2005 12:55:15 -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 1Cud91-00046x-Ov; Fri, 28 Jan 2005 20:55:07 +0000 Message-ID: <41FAA6AE.6030605@franklinmint.fm> Date: Fri, 28 Jan 2005 15:55:10 -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: Joe Gregorio , Atom Syntax Subject: Re: PaceFormatSecurity References: <3f1451f50501281137226f64f4@mail.gmail.com> <9c7695aad7004a39f148af7e39fd83fc@mac.com> In-Reply-To: <9c7695aad7004a39f148af7e39fd83fc@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: > I don't like stuff like: > "All SCRIPT elements should be stripped from Text Constructs or all > native > scripting support of the (X)HTML display engine should be disabled." > > I don't think you need to should do any more than outline the threat > model from each tech. Proscribing how to deal with it is not on, > especially when they're this drastic. Agree w/ Graham. We don't know what kind of relationship the publisher and consumer have. I would strike all the details on HTML, leave the first paragraph, and refer to the security sections of RFC 2854 and HTML 4.01. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Jan 28 16:08: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 QAA13362 for ; Fri, 28 Jan 2005 16:08: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 j0SKv7Jb091103; Fri, 28 Jan 2005 12: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 j0SKv7pI091102; Fri, 28 Jan 2005 12:57:07 -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 j0SKv64X091096 for ; Fri, 28 Jan 2005 12:57:06 -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 j0SKv0dt028668 for ; Fri, 28 Jan 2005 13:57:06 -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 <0IB100C2LOV0L9@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 28 Jan 2005 13:57:00 -0700 (MST) Received: from [192.168.1.4] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IB1005JVOUZUK@mail.sun.net> for atom-syntax@imc.org; Fri, 28 Jan 2005 13:56:59 -0700 (MST) Date: Fri, 28 Jan 2005 12:56:58 -0800 From: Tim Bray Subject: Re: PaceFormatSecurity In-reply-to: <9c7695aad7004a39f148af7e39fd83fc@mac.com> To: Graham Cc: Joe Gregorio , Atom Syntax Message-id: <266D9952-716F-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: <3f1451f50501281137226f64f4@mail.gmail.com> <9c7695aad7004a39f148af7e39fd83fc@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 28, 2005, at 12:09 PM, Graham wrote: > I don't like stuff like: > "All SCRIPT elements should be stripped from Text Constructs or all > native > scripting support of the (X)HTML display engine should be disabled." > > I don't think you need to should do any more than outline the threat > model from each tech. Proscribing how to deal with it is not on, > especially when they're this drastic. I tend to agree with Graham; point out the potential security hole and give some indication of its seriousness and abuse potential, but don't prescribe how to deal with it. At this point we should appeal to our designated IETF culture/process experts; Scott/Ted/Paul, any guidance? -Tim PS: Good work, Joe, thanks. From owner-atom-syntax@mail.imc.org Fri Jan 28 16:32: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 QAA18494 for ; Fri, 28 Jan 2005 16: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 j0SLLD3g092919; Fri, 28 Jan 2005 13: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 j0SLLDQU092918; Fri, 28 Jan 2005 13:21:13 -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 j0SLLCGj092911 for ; Fri, 28 Jan 2005 13:21:12 -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 j0SLLCVu000620 for ; Fri, 28 Jan 2005 14:21:12 -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 <0IB100C4FPZBCA@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 28 Jan 2005 14:21:11 -0700 (MST) Received: from [192.168.1.4] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IB1005XAPZ9UN@mail.sun.net> for atom-syntax@imc.org; Fri, 28 Jan 2005 14:21:11 -0700 (MST) Date: Fri, 28 Jan 2005 13:21:08 -0800 From: Tim Bray Subject: Re: PaceFormatSecurity In-reply-to: <41FAA6AE.6030605@franklinmint.fm> To: Robert Sayre Cc: Graham , Joe Gregorio , Atom Syntax Message-id: <8707B238-7172-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: <3f1451f50501281137226f64f4@mail.gmail.com> <9c7695aad7004a39f148af7e39fd83fc@mac.com> <41FAA6AE.6030605@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 28, 2005, at 12:55 PM, Robert Sayre wrote: > I would strike all the details on HTML, leave the first paragraph, and > refer to the security sections of RFC 2854 and HTML 4.01. Whereas you could technically get by with warning-by-reference, I think that it's OK and fact probably essential to point out that and