, > <summary>, <link>, <content>, etc. > > * Property and entity elements are all fully qualified, either > in the core Atom namespace or an extension namespace. Examples > usually show elements in the Atom namespace using a default > namespace on the root entity element. > > * <content> and content-like elements (title, subtitle, and > summary) have an associated a MIME type, mode of encoding, > language, and either a value inline or through a URI > reference. A <content> element may have a relation that > indicates whether the content is an excerpt, preview, thumbnail, > or otherwise not the entire content. I thought it would be a good inaugural message to the list, to start with a general discussion as to the style or pattern to the schema rather than jumping straight to individual element-content models. As always, these are not cast in stone. There is still discussion in EscapedHtmlContent about what <content> may hold (is it limited to just *ML, or should *ML types be special-cased). There is discussion in ContentProblems regarding the distinction between whole and partial entities. ContentDiscussion appears to have a simple majority preferring only one <content>, but current examples are multiple-contents with an undefined model for selecting a representation. The utility of <content src='...'> appears to be in question, but if it is useful, is a MIME multipart wrapper not far behind (a la SOAP with Attachments)? Since the decision was made to specify model and syntax in one document (SyntaxConsiderations), I presume this list covers both? -- Ken From owner-atom-syntax Thu Jul 17 15:48:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HMmbqt032282 for <atom-syntax-bks@above.proper.com>; Thu, 17 Jul 2003 15:48:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6HMmb8n032281 for atom-syntax-bks; Thu, 17 Jul 2003 15:48:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HMmZqt032274 for <atom-syntax@above.proper.com>; Thu, 17 Jul 2003 15:48:35 -0700 (PDT) (envelope-from tbray@textuality.com) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id 373D21031B for <atom-syntax@above.proper.com>; Thu, 17 Jul 2003 15:48:38 -0700 (PDT) Message-ID: <3F1727C6.3080102@textuality.com> Date: Thu, 17 Jul 2003 15:48:38 -0700 From: Tim Bray <tbray@textuality.com> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@above.proper.com Subject: Testing Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> 1 2 3 -- Cheers, Tim Bray (ongoing fragmented essay: http://www.tbray.org/ongoing/) From owner-atom-syntax Fri Jul 18 13:53:52 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IKrqqt021496 for <atom-syntax-bks@above.proper.com>; Fri, 18 Jul 2003 13:53:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6IKrqM3021494 for atom-syntax-bks; Fri, 18 Jul 2003 13:53:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IKrpqt021488 for <atom-syntax@imc.org>; Fri, 18 Jul 2003 13:53:51 -0700 (PDT) (envelope-from joe@bitworking.org) Received: from bitworking.org (198-143-226-158.dsl.btitelecom.net [198.143.226.158]) (authenticated) by scandium.sabren.com (8.11.6/8.11.6) with ESMTP id h6IKvDO07834 for <atom-syntax@imc.org>; Fri, 18 Jul 2003 16:57:13 -0400 Message-ID: <3F185F8A.3060208@bitworking.org> Date: Fri, 18 Jul 2003 16:58:50 -0400 From: Joe Gregorio <joe@bitworking.org> User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Testing References: <200307161333.h6GDXb4b082599@above.proper.com> In-Reply-To: <200307161333.h6GDXb4b082599@above.proper.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: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Testing From owner-atom-syntax Fri Jul 18 18:44:47 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6J1ilqt035926 for <atom-syntax-bks@above.proper.com>; Fri, 18 Jul 2003 18:44:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6J1ilI1035925 for atom-syntax-bks; Fri, 18 Jul 2003 18:44:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6J1ikqt035920 for <atom-syntax@imc.org>; Fri, 18 Jul 2003 18:44:46 -0700 (PDT) (envelope-from joe@bitworking.org) Received: from bitworking.org (adsl-80-203-24.rdu.bellsouth.net [65.80.203.24]) (authenticated) by scandium.sabren.com (8.11.6/8.11.6) with ESMTP id h6J1m6D21311 for <atom-syntax@imc.org>; Fri, 18 Jul 2003 21:48:06 -0400 Message-ID: <3F18A287.1000209@bitworking.org> Date: Fri, 18 Jul 2003 21:44:39 -0400 From: Joe Gregorio <joe@bitworking.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Test Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Testing. From owner-atom-syntax Sat Jul 19 05:12:51 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JCCpqt087247 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 05:12:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JCCpYT087246 for atom-syntax-bks; Sat, 19 Jul 2003 05:12:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vsmtp3.tin.it (vsmtp3.tin.it [212.216.176.223]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JCCoqt087240 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 05:12:50 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from trotter (80.182.204.218) by vsmtp3.tin.it (7.0.019) id 3F16C22A000931E1 for atom-syntax@imc.org; Sat, 19 Jul 2003 14:12:50 +0200 Reply-To: <danny666@virgilio.it> From: "Danny Ayers" <danny666@virgilio.it> To: <atom-syntax@imc.org> Subject: Extension mechanism Date: Sat, 19 Jul 2003 14:08:16 +0200 Message-ID: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal 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> Hi folks, Great to see the list. One thing about the syntax that concerns me greatly is that there doesn't yet appear to be a consistent way of interpreting material from other namespaces. I believe this to be a make or break issue for interop. Such a mechanism is also lacking from RSS 2.0, which relies on extension modules to define how they are to be used. This approach is IMHO totally inadequate, the main reason be that it is likely to lead to inconsistency in the way external data has to be handled by an Atom processor. This will make coding harder. The issue was however thoroughly covered in RSS 1.0 thanks to RDF/XML. I doubt very much that the richness of the full RDF graph is needed inside Atom, but I think it will be desirable to be able to extend into or attach a full graph if required. In fact, another justification for a sound extension mechanism is to be able to interoperate with RSS 1.0 and other RDF data. It has been suggested that "ignore anything you don't recognise" might be a suitable mechanism, but I believe this has two major flaws : the parts that aren't recognised may alter the meaning of other parts of the feed (e.g. a Creative Commons license, or a element saying "this is all a joke"), so their total omission may have side effects; valuable data is being thrown away (compare the RDF approach). A start has been made on defining extension modules on the Wiki [1], but as yet there doesn't seem to be anything substantial. I believe that such a mechanism can be defined without any impact on the work that has been done so far. All I think that is needed in the core is a means of saying whether an included element from another namespace is additional content, *or* is additional information about its parent. I've put a strawman on the Wiki [2], in brief : 1. Any elements outside of the Atom namespace within a <metadata> element will be interpreted as being about the parent element. 2. Any other elements outside of the Atom namespace will be interpreted as secondary content associated with their parent element. The use of a <metadata> element has prior art in SVG [3], where it seems to work quite well. Cheers, Danny. [1] http://www.intertwingly.net/wiki/pie/ExtensionModule [2] http://www.intertwingly.net/wiki/pie/SyntaxExtensionMechanism [3] http://www.w3.org/TR/SVG/metadata.html ---- http://dannyayers.com From owner-atom-syntax Sat Jul 19 06:05:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JD59qt090497 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 06:05:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JD59kh090495 for atom-syntax-bks; Sat, 19 Jul 2003 06:05:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [209.61.183.90]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JD57qt090486 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 06:05:07 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-066.nc.rr.com [66.57.27.66]) (authenticated) by chromium.sabren.com (8.11.6/8.11.6) with ESMTP id h6JD5Bn11118 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 09:05:12 -0400 Message-ID: <3F1941E7.4000901@intertwingly.net> Date: Sat, 19 Jul 2003 09:04:39 -0400 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Extension mechanism References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> In-Reply-To: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Danny Ayers wrote: > > I believe that such a mechanism can be defined without any impact on the > work that has been done so far. All I think that is needed in the core is a > means of saying whether an included element from another namespace is > additional content, *or* is additional information about its parent. I've > put a strawman on the Wiki [2] WOW. Orthogonal Extensibility. Love it. Contrast: <Envelope> <Header>  </Header> <Body> <entry>  </entry> </Body> </Envelope> With: <entry>  <metadata>  </metadata> </entry> A few points: * metadata is actually a matter of perspective. Is the issued date content or metadata? If LiveJournal wants to capture the mood of the person while composing this entry, is that additional content or additional information about the entry? * if we go down this path, it would be worth having something analagous to the 'mustUnderstand' attribute as defined in the SOAP specification. - Sam Ruby From owner-atom-syntax Sat Jul 19 06:04:08 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JD48qt090343 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 06:04:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JD4818090341 for atom-syntax-bks; Sat, 19 Jul 2003 06:04:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (law12-oe49.law12.hotmail.com [64.4.18.21]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JD46qt090323 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 06:04:06 -0700 (PDT) (envelope-from wkearney99@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 19 Jul 2003 06:04:02 -0700 Received: from 66.92.145.79 by law12-oe49.law12.hotmail.com with DAV; Sat, 19 Jul 2003 13:04:02 +0000 X-Originating-IP: [66.92.145.79] X-Originating-Email: [wkearney99@hotmail.com] Reply-To: "Bill Kearney" <wkearney99@hotmail.com> From: "Bill Kearney" <wkearney99@hotmail.com> To: <atom-syntax@imc.org> References: <3F18A287.1000209@bitworking.org> Subject: Re: Test Date: Sat, 19 Jul 2003 09:04:01 -0400 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 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Message-ID: <Law12-OE494lB4BwOZx0000d699@hotmail.com> X-OriginalArrivalTime: 19 Jul 2003 13:04:02.0586 (UTC) FILETIME=[39F077A0:01C34DF6] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> 1... 2... 3... ----- Original Message ----- From: "Joe Gregorio" <joe@bitworking.org> To: <atom-syntax@imc.org> Sent: Friday, July 18, 2003 9:44 PM Subject: Test > > Testing. > > From owner-atom-syntax Sat Jul 19 06:34:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JDYnqt095870 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 06:34:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JDYnYN095869 for atom-syntax-bks; Sat, 19 Jul 2003 06:34:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (law12-oe64.law12.hotmail.com [64.4.18.199]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JDYlqt095837 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 06:34:48 -0700 (PDT) (envelope-from wkearney99@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 19 Jul 2003 06:34:38 -0700 Received: from 66.92.145.79 by oe64.adinternal.hotmail.com with DAV; Sat, 19 Jul 2003 13:34:38 +0000 X-Originating-IP: [66.92.145.79] X-Originating-Email: [wkearney99@hotmail.com] Reply-To: "Bill Kearney" <wkearney99@hotmail.com> From: "Bill Kearney" <wkearney99@hotmail.com> To: "atom-syntax" <atom-syntax@imc.org> References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1941E7.4000901@intertwingly.net> Subject: prefixing mailing list messages? Date: Sat, 19 Jul 2003 09:34:43 -0400 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 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Message-ID: <LAW12-OE649yfB4mvo9000053d5@hotmail.com> X-OriginalArrivalTime: 19 Jul 2003 13:34:38.0843 (UTC) FILETIME=[806F0CB0:01C34DFA] 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> Can we had the [atom-syntax] prefix prefixed in the subject line of messages from the mailing list? It makes sorting the out in the inbox a bit easier. And no, header lines don't really help. Thanks, -Bill Kearney From owner-atom-syntax Sat Jul 19 07:08:14 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JE8Eqt098215 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 07:08:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JE8EXp098214 for atom-syntax-bks; Sat, 19 Jul 2003 07:08:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta2-svc.business.ntl.com (mta2-svc.business.ntl.com [62.253.164.42]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JE8Bqt098204 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 07:08:12 -0700 (PDT) (envelope-from nick@willow.frejol.org) Received: from willow.frejol.org ([80.1.28.119]) by mta2-svc.business.ntl.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20030719140810.RBP18309.mta2-svc.business.ntl.com@willow.frejol.org> for <atom-syntax@imc.org>; Sat, 19 Jul 2003 15:08:10 +0100 Message-ID: <3F1950C9.2040107@willow.frejol.org> Date: Sat, 19 Jul 2003 15:08:09 +0100 From: Nick Boalch <nick@willow.frejol.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030701 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: prefixing mailing list messages? References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1941E7.4000901@intertwingly.net> <LAW12-OE649yfB4mvo9000053d5@hotmail.com> In-Reply-To: <LAW12-OE649yfB4mvo9000053d5@hotmail.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: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Bill Kearney wrote: > Can we had the [atom-syntax] prefix prefixed in the subject line of messages > from the mailing list? While we're doing issues with the list mechanics (atom-syntax-syntax? :) is there any chance of having Mail-Followup-To: set appropriately by the list software? Cheers, N. -- Nick Boalch <URL:http://nick.frejol.org/> From owner-atom-syntax Sat Jul 19 07:18:39 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JEIdqt098393 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 07:18:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JEIdCu098389 for atom-syntax-bks; Sat, 19 Jul 2003 07:18:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (law12-oe22.law12.hotmail.com [64.4.18.79]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JEIbqt098382 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 07:18:38 -0700 (PDT) (envelope-from wkearney99@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 19 Jul 2003 07:18:33 -0700 Received: from 66.92.145.79 by law12-oe22.law12.hotmail.com with DAV; Sat, 19 Jul 2003 14:18:33 +0000 X-Originating-IP: [66.92.145.79] X-Originating-Email: [wkearney99@hotmail.com] Reply-To: "Bill Kearney" <wkearney99@hotmail.com> From: "Bill Kearney" <wkearney99@hotmail.com> To: <atom-syntax@imc.org> References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1941E7.4000901@intertwingly.net> <LAW12-OE649yfB4mvo9000053d5@hotmail.com> <3F1950C9.2040107@willow.frejol.org> Subject: Re: prefixing mailing list messages? Date: Sat, 19 Jul 2003 10:18:33 -0400 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 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Message-ID: <Law12-OE22dmXYJrOOO0000df4d@hotmail.com> X-OriginalArrivalTime: 19 Jul 2003 14:18:33.0990 (UTC) FILETIME=[A31A9260:01C34E00] 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> This is an OLD argument. Some folks strongly disagree with this idea. I greatly prefer reply-to being the list and support Nick's suggestion. It also avoids the insane reply-to-all hassles of the thread particpants getting two copies. Yes, mail client software can be used to work around it. But most MUAs do a bad job of this. -Bill Kearney ----- Original Message ----- From: "Nick Boalch" <nick@willow.frejol.org> To: <atom-syntax@imc.org> Sent: Saturday, July 19, 2003 10:08 AM Subject: Re: prefixing mailing list messages? > > Bill Kearney wrote: > > Can we had the [atom-syntax] prefix prefixed in the subject line of messages > > from the mailing list? > > While we're doing issues with the list mechanics (atom-syntax-syntax? :) > is there any chance of having Mail-Followup-To: set appropriately by the > list software? From owner-atom-syntax Sat Jul 19 07:18:40 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JEIeqt098396 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 07:18:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JEIeBL098395 for atom-syntax-bks; Sat, 19 Jul 2003 07:18:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta2-svc.business.ntl.com (mta2-svc.business.ntl.com [62.253.164.42]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JEIcqt098387 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 07:18:39 -0700 (PDT) (envelope-from nick@willow.frejol.org) Received: from willow.frejol.org ([80.1.28.119]) by mta2-svc.business.ntl.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20030719141838.YNW18309.mta2-svc.business.ntl.com@willow.frejol.org> for <atom-syntax@imc.org>; Sat, 19 Jul 2003 15:18:38 +0100 Message-ID: <3F19533D.3050509@willow.frejol.org> Date: Sat, 19 Jul 2003 15:18:37 +0100 From: Nick Boalch <nick@willow.frejol.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030701 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Extension mechanism References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1941E7.4000901@intertwingly.net> In-Reply-To: <3F1941E7.4000901@intertwingly.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: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Sam Ruby wrote: > metadata is actually a matter of perspective. Is the issued date > content or metadata? To my mind, the issued date is definitely metadata -- particularly as our projected format supports various different kinds of date metadata about a given entry (created, issued, modified, &c, &c). > If LiveJournal wants to capture the mood of the person while composing > this entry, is that additional content or additional information about > the entry? This one's more ambiguous. I'd call it as additional content, I think, purely on the basis of safe generalisation. Sure, in many cases such information could arguably be considered metadata, but I reckon I can project a number of examples where 'mood' isn't a useful piece of additional information about an entry. Cheers, N. -- Nick Boalch <URL:http://nick.frejol.org/> From owner-atom-syntax Sat Jul 19 07:56:57 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JEuvqt099094 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 07:56:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JEuvpB099093 for atom-syntax-bks; Sat, 19 Jul 2003 07:56:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vsmtp12.tin.it (vsmtp12.tin.it [212.216.176.206]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JEuuqt099081 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 07:56:56 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from trotter (80.182.209.190) by vsmtp12.tin.it (6.7.016) id 3EE0612D00AD5B30; Sat, 19 Jul 2003 16:56:30 +0200 Reply-To: <danny666@virgilio.it> From: "Danny Ayers" <danny666@virgilio.it> To: "Sam Ruby" <rubys@intertwingly.net>, <atom-syntax@imc.org> Subject: RE: Extension mechanism Date: Sat, 19 Jul 2003 16:51:55 +0200 Message-ID: <BKELLDAGKABIOCHDFDBPMEIODGAA.danny666@virgilio.it> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3F1941E7.4000901@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> > Contrast: > > <Envelope> > <Header> >  > </Header> > <Body> > <entry> >  > </entry> > </Body> > </Envelope> > > With: > > <entry> >  > <metadata> >  > </metadata> > </entry> A very interesting comparison! > A few points: > > * metadata is actually a matter of perspective. Is the issued date > content or metadata? If LiveJournal wants to capture the mood of the > person while composing this entry, is that additional content or > additional information about the entry? That's true, the content/meta divide is quite artificial (the same applies with the head/body approach). My thinking behind interpreting the (kind of) default inclusion as content is that a newsreader could just display it without thinking, whereas the <metadata> wrapper would be a big hint that perhaps this shouldn't simply be rendered in the viewer directly. I could be wrong, but it feels like this approach may make life easier at either end, and doesn't interfere with the rest of the syntax. > * if we go down this path, it would be worth having something analagous > to the 'mustUnderstand' attribute as defined in the SOAP specification. That sounds a very promising way of dealing with extensions that might say things like "not for republication". Cheers, Danny. From owner-atom-syntax Sat Jul 19 08:07:59 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JF7xqt099260 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 08:07:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JF7xQH099259 for atom-syntax-bks; Sat, 19 Jul 2003 08:07:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JF7wqt099254 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 08:07:58 -0700 (PDT) (envelope-from tbray@textuality.com) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id 7C3AF1032A; Sat, 19 Jul 2003 08:07:59 -0700 (PDT) Message-ID: <3F195ECD.3000102@textuality.com> Date: Sat, 19 Jul 2003 08:07:57 -0700 From: Tim Bray <tbray@textuality.com> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby <rubys@intertwingly.net> Cc: atom-syntax@imc.org Subject: Re: Extension mechanism References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1941E7.4000901@intertwingly.net> In-Reply-To: <3F1941E7.4000901@intertwingly.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: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> > Danny Ayers wrote: >> >> I believe that such a mechanism can be defined without any impact on the >> work that has been done so far. All I think that is needed in the core >> is a >> means of saying whether an included element from another namespace is >> additional content, *or* is additional information about its parent. It's worth exploring, but could be a rat-hole. The line between metadata and data is super-fuzzy. Also, unless we can figure out how to be really clear what the expected impact on client software is, it's not worth doing. Sam Ruby wrote: > * metadata is actually a matter of perspective. Is the issued date > content or metadata? If LiveJournal wants to capture the mood of the > person while composing this entry, is that additional content or > additional information about the entry? Yep. THere are going to be a million corner cases. > * if we go down this path, it would be worth having something analagous > to the 'mustUnderstand' attribute as defined in the SOAP specification. This seems like a good idea, it's been more or less proven to work in the SOAP context. As I've said before, we shouldn't be trying to invent whizzy new technology here, we should just be trying for a clean clear specification of what's been proven to work. -- Cheers, Tim Bray (ongoing fragmented essay: http://www.tbray.org/ongoing/) From owner-atom-syntax Sat Jul 19 08:09:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JF9qqt099316 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 08:09:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JF9q21099315 for atom-syntax-bks; Sat, 19 Jul 2003 08:09:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JF9kqt099309 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 08:09:46 -0700 (PDT) (envelope-from tbray@textuality.com) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id 522351032A; Sat, 19 Jul 2003 08:09:48 -0700 (PDT) Message-ID: <3F195F3A.5020904@textuality.com> Date: Sat, 19 Jul 2003 08:09:46 -0700 From: Tim Bray <tbray@textuality.com> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: danny666@virgilio.it Cc: atom-syntax@imc.org Subject: Re: Extension mechanism References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> In-Reply-To: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Danny Ayers wrote: > One thing about the syntax that concerns me greatly is that there doesn't > yet appear to be a consistent way of interpreting material from other > namespaces. I believe this to be a make or break issue for interop. This problem has never been solved in the general case that I know of. So I really hope that you're wrong on it's make-or-break-ness. Worth taking a whack at, but don't underestimate the difficulty. -- Cheers, Tim Bray (ongoing fragmented essay: http://www.tbray.org/ongoing/) From owner-atom-syntax Sat Jul 19 08:40:18 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JFeIqt000555 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 08:40:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JFeIme000554 for atom-syntax-bks; Sat, 19 Jul 2003 08:40:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vsmtp3.tin.it (vsmtp3.tin.it [212.216.176.223]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JFeHqt000543 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 08:40:17 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from trotter (80.182.209.190) by vsmtp3.tin.it (7.0.019) id 3F16C22A0009C854; Sat, 19 Jul 2003 17:40:12 +0200 Reply-To: <danny666@virgilio.it> From: "Danny Ayers" <danny666@virgilio.it> To: "Tim Bray" <tbray@textuality.com> Cc: <atom-syntax@imc.org> Subject: RE: Extension mechanism Date: Sat, 19 Jul 2003 17:35:36 +0200 Message-ID: <BKELLDAGKABIOCHDFDBPEEJBDGAA.danny666@virgilio.it> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3F195F3A.5020904@textuality.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> > > One thing about the syntax that concerns me greatly is that > there doesn't > > yet appear to be a consistent way of interpreting material from other > > namespaces. I believe this to be a make or break issue for interop. > > This problem has never been solved in the general case that I know of. > So I really hope that you're wrong on it's make-or-break-ness. Worth > taking a whack at, but don't underestimate the difficulty. (also >As I've said before, we shouldn't be trying to invent whizzy new >technology here, we should just be trying for a clean clear >specification of what's been proven to work.) I believe there is adequate (working!) prior art to point to something that will be appropriate for Atom. I reckon the techniques have been proven, it's just a matter of finding the sweet spot. RDF/XML guarantees we know *something* about material from other namespaces through conformity to the RDF model. It's already been decided that the uber-model approach of using a complete abstract language from which the syntax is derived (as in RDF) isn't desirable, yet RSS 1.0 shows that this approach is possible in the context of syndication. At the other extreme, Sam and others have experimented with directly inserting namespace-qualified xhtml into RSS feeds with the intention that it's there for "display as content". This worked. (Though I can't remember offhand how conflict with other content was handled). Element-wrapping of metadata to hide it is a technique proven in SVG. So I think a braindead simple "this is metadata"/"this is content" data model (expressed in the syntax) for extension material could work. My suggestion for the syntax almost certainly isn't ideal, but it's maybe a start. Cheers, Danny. From owner-atom-syntax Sat Jul 19 08:42:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JFgYqt000848 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 08:42:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JFgYdN000847 for atom-syntax-bks; Sat, 19 Jul 2003 08:42:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from localhost.localdomain (CPE-65-30-234-116.mn.rr.com [65.30.234.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JFgWqt000832 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 08:42:32 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h6JFjdlg023422 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 10:45:39 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h6JFjcYV023418; Sat, 19 Jul 2003 10:45:38 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: <atom-syntax@imc.org> Subject: Re: Extension mechanism References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> From: Ken MacLeod <ken@bitsko.slc.ut.us> Date: 19 Jul 2003 10:45:38 -0500 In-Reply-To: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> Message-ID: <m3adbaa5b1.fsf@bitsko.slc.ut.us> Lines: 36 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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> I think making a distinction, outside of <content>, between what might be "metadata" and what might be "data" is a mistake. Virtually everything we're specifying already *is* metadata about a resource. From Danny's description of a <metadata> element for a feed or an entry, that means we have metadata for our metadata. I think the confusion comes from not knowing whether <entry> is the resource itself vs. <entry> being metadata about another resource (some entity logically or physically in <content>). While it is true that RDF is very clear about this (for any given subject URI, all its properties describe only that subject), RSS 1.0 actually has the same confusion we're talking about here. RSS 1.0 says the subject (rdf:about) of an item "is a URI which identifies the item", but it doesn't make clear whether "the item" is another resource or whether the <rss:item> RDF description itself can be the item. Most common usage is the former, but the latter is often used or proposed for things like tickers, playlists, or other ordered items where the items themselves are the subjects -- many of the same things proposed for Atom. I believe the answer to the question of "is this metadata about a resource or is this entry the resource" is centered around <content>. If content is a complete entity (embedded or by reference), this entry is metadata about the entity resource. If content is not present, empty, or is an entity fragment (the body of a log entry or comment, for example), the entry itself is the resource (content is the body value). In _either_ case, direct children of <entry> describe _the resource_ (as just defined). -- Ken P.S. +1 on a mustUnderstand facility. From owner-atom-syntax Sat Jul 19 09:07:46 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JG7jqt002329 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 09:07:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JG7jpG002328 for atom-syntax-bks; Sat, 19 Jul 2003 09:07:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from localhost.localdomain (CPE-65-30-234-116.mn.rr.com [65.30.234.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JG7iqt002321 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 09:07:44 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h6JGAplg023559 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 11:10:51 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h6JGApHr023555; Sat, 19 Jul 2003 11:10:51 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: <atom-syntax@imc.org> Subject: Re: Extension mechanism References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> From: Ken MacLeod <ken@bitsko.slc.ut.us> Date: 19 Jul 2003 11:10:50 -0500 In-Reply-To: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> Message-ID: <m365lya451.fsf@bitsko.slc.ut.us> Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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> Here are some other facets I see surrounding extension mechanisms, with my preferences stated below: "Wrapping" or "boxing" extensions Extension modules define a wrapper element, properties of the extension appear as children of the extension. Entities and Properties Certain elements are identified as "entities" (as in "entity-relationship model" for RDBs or as classes in OO or RDF). Direct child elements of those entities are either properties or other entities. Entities and properties are fully qualified, either in the core Atom namespace or an extension namespace. Display unknown entities/properties by default Don't display unknown entities/properties by default This relates to how one "ignores what they don't understand." In HTML <body>, unknown elements are treated as if the element tags didn't exist -- their content is displayed by default. My preference is for "Entities and Properties" and "Don't display unknown entities/properties by default." The latter is somewhat in perspective of the former: if these are like columns in a table (where everybody can add their own columns), it doesn't make sense to arbitrarily display every column value. Instead, display well-known columns, columns the user asks for, and columns where another extension column flags that they should be displayed (ie. by providing a stylesheet). -- Ken From owner-atom-syntax Sat Jul 19 09:08:23 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JG8Mqt002339 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 09:08:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JG8M5B002338 for atom-syntax-bks; Sat, 19 Jul 2003 09:08:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ehost004.intermedia.net (ehost004.intermedia.net [206.40.48.177]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JG8Lqt002333 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 09:08:21 -0700 (PDT) (envelope-from joe.madia@workstate.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Extension mechanism Date: Sat, 19 Jul 2003 09:08:22 -0700 Message-ID: <FF1837A1813CF54F8A3579D3F46EB40F038B29EA@ehost004.intermedia.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Extension mechanism Thread-Index: AcNOD+KaeUmsx45OR0mS08hkGCH1Jg== From: "Joe Madia" <joe.madia@workstate.com> To: <atom-syntax@imc.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6JG8Mqt002334 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> A big +1 on attempting to work out some sort of mustUnderstand rule for Atom extensions. On the flip side, I completely agree with Tim's hesitance/pragmatism regarding this issue. My biggest concern: The mustUnderstand header is used successfully in 'some other access protocols' because a rigid processing model is also defined. Atom does not currently (and probably should not) have a predefined processing model and this may limit the ability to add some type of mustUnderstand construct. In spite of the potential problems, I think we should try to work something out... if it becomes a rat hole then we'll just abandon it and move on. Joe From owner-atom-syntax Sat Jul 19 11:07:28 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JI7Sqt007047 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 11:07:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JI7SKq007046 for atom-syntax-bks; Sat, 19 Jul 2003 11:07:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from localhost.localdomain (CPE-65-30-234-116.mn.rr.com [65.30.234.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JI7Rqt007041 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 11:07:27 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h6JIAalg024147 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 13:10:36 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h6JIAZ18024143; Sat, 19 Jul 2003 13:10:35 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: <atom-syntax@imc.org> Subject: Re: Extension mechanism References: <BKELLDAGKABIOCHDFDBPAEJDDGAA.danny666@virgilio.it> From: Ken MacLeod <ken@bitsko.slc.ut.us> Date: 19 Jul 2003 13:10:35 -0500 In-Reply-To: <BKELLDAGKABIOCHDFDBPAEJDDGAA.danny666@virgilio.it> Message-ID: <m3znja8k10.fsf@bitsko.slc.ut.us> Lines: 61 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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> "Danny Ayers" <danny666@virgilio.it> writes: > I was thinking the <metadata> element could go anywhere, so it might > not be about an entry or the feed - the other obvious example being > for it to apply to the <author> of a feed (e.g. some FOAF). > But I'm not sure this is an issue that affects the <metadata> > element if you can put it where you like : > > <link>/weblog/archive/45.html<metadata>...</metadata></link> > > <content> > ...blah... > <metadata>...</metadata> > </content> > > (the link one is a bit ugly-looking, hmm...) <link> and <content> are literal values. Additional markup can only be embedded within them according to their content models. <link> would be #PCDATA and I don't think anyone wants to complicate that by saying element markup can go in there. <content> is based on its media type, but would still logically either be #PCDATA or a content model defined by some other specification (or an Atom content module, as in ComponentBlog). Other elements, like <author>, may themselves be "entity" elements and allow extended properties directly as children. > [...] it doesn't really answer how one might inline content from > another (unknown, arbitrary) namespace - let's say we wanted some > text plus a bit of SVG. If the rule was such content had to go in a > content element of its own, I guess that would work. This was the problem I saw with xhtml:body in RSS that we've solved far more neatly with atom:content. The problem was that xhtml:body is more a "type" than a property name; atom:content is a property name. As far as inlining content from another namespace, the same pattern applies: give it a property name -- the content model is constrained by the schema that defines the property name (readers should expect arbitrary XML for unknown properties). > btw, I personally don't really care too much how this is done, but I > think not sorting it out now would in effect be leaving the broadest > set of use cases (those involving extensions - topics, reviews, > threads, foaf etc etc) without a hook on which to hang their > data. I agree. I described a syntax pattern in Syntax[1] that I believe snapshots a common view of the Atom pattern, but there's not consensus on every part, which I wrote here[2] before the mail list was working right. I think it's very important that we define a general pattern for schema syntaxes so property or extension models are consistent and easier to develop without having to always rethink basic practices. -- Ken [1] http://intertwingly.net/wiki/pie/Syntax [2] http://www.imc.org/atom-syntax/mail-archive/msg00000.html From owner-atom-syntax Sat Jul 19 11:39:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JIdYqt007874 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 11:39:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JIdYjC007873 for atom-syntax-bks; Sat, 19 Jul 2003 11:39:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vsmtp12.tin.it (vsmtp12.tin.it [212.216.176.206]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JIdXqt007840 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 11:39:33 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from trotter (80.182.210.43) by vsmtp12.tin.it (6.7.016) id 3EE0612D00ADCF6F; Sat, 19 Jul 2003 20:39:21 +0200 Reply-To: <danny666@virgilio.it> From: "Danny Ayers" <danny666@virgilio.it> To: "Ken MacLeod" <ken@bitsko.slc.ut.us>, <atom-syntax@imc.org> Subject: RE: Extension mechanism Date: Sat, 19 Jul 2003 20:34:45 +0200 Message-ID: <BKELLDAGKABIOCHDFDBPGEJGDGAA.danny666@virgilio.it> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <m3znja8k10.fsf@bitsko.slc.ut.us> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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> Heh, I must apologise - I only scanned your previous mail, its significance in the context of an extension mechanism flew right past me. > I described a syntax pattern in Syntax[1] that I believe snapshots a > common view of the Atom pattern, but there's not consensus on every > part, which I wrote here[2] before the mail list was working right. > > I think it's very important that we define a general pattern for > schema syntaxes so property or extension models are consistent and > easier to develop without having to always rethink basic practices. Agreed. The "Entity" elements you describe sound mightily like web resources - will these entities each have a URI? Similarly, the property elements correspond well to the parts of RDF with the same name - this could be a big plus for interop. Cheers, Danny. > -- Ken > > [1] http://intertwingly.net/wiki/pie/Syntax > [2] http://www.imc.org/atom-syntax/mail-archive/msg00000.html From owner-atom-syntax Sat Jul 19 13:51:28 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JKpSqt014327 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 13:51:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JKpSwC014325 for atom-syntax-bks; Sat, 19 Jul 2003 13:51:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from gkhs.net (exim@spark.gkhs.net [81.6.252.146]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JKpRqt014320 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 13:51:27 -0700 (PDT) (envelope-from aq+lists@gkhs.net) Received: from maelstrom.water.gkhs.net ([10.1.0.3]) by gkhs.net with smtp (Exim 4.10) id 19dyfw-0001e0-00 for atom-syntax@imc.org; Sat, 19 Jul 2003 21:51:28 +0100 From: Aquarion <aq+lists@gkhs.net> To: atom-syntax@imc.org Subject: Re: Extension mechanism Date: Sat, 19 Jul 2003 21:51:40 +0100 Message-ID: <ebbjhvghjgsspbmodfee0u6ojs3g7h4r9j@4ax.com> References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1941E7.4000901@intertwingly.net> <3F19533D.3050509@willow.frejol.org> In-Reply-To: <3F19533D.3050509@willow.frejol.org> X-Mailer: Forte Agent 1.93/32.576 English (American) 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 h6JKpSqt014321 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> On Sat, 19 Jul 2003 15:18:37 +0100, in gkhs.weblogs.atom-syntax you wrote: > >Sam Ruby wrote: > >> metadata is actually a matter of perspective. Is the issued date >> content or metadata? > >To my mind, the issued date is definitely metadata -- particularly as >our projected format supports various different kinds of date metadata >about a given entry (created, issued, modified, &c, &c). > >> If LiveJournal wants to capture the mood of the person while composing >> this entry, is that additional content or additional information about >> the entry? > >This one's more ambiguous. I'd call it as additional content, I think, >purely on the basis of safe generalisation. Sure, in many cases such >information could arguably be considered metadata, but I reckon I can >project a number of examples where 'mood' isn't a useful piece of >additional information about an entry. So how about if there were two container classes, <content> and <metadata> with same spec, to give the client a hint as to if it should be contained or just referenced to. For example: <atomExample> <content> <item type="text/plain" lang="en">Hello World!</item> <item type="image/gif" src="http://www.aquarionics.com/assets/hello.gif">Hello World image</item> </content> <metadata> <item type="audio/mp3" src="http://www.aquarionics.com/assets/hello.mp3">Aquarion reading "Hello World"</item> <dc:subject>Greetings</dc:subject> <link rel="crossreference" href="http://www2.latech.edu/~acm/HelloWorld.shtml">Hello World in different languages</link> </metadata> </atomExample> This leaves the decision of MetaData up to - primarily - the feed producer and - secondarily - the user agent. -- Aquarion http://www.aquarionics.com From owner-atom-syntax Sat Jul 19 15:06:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JM6bqt019795 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 15:06:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JM6bHN019794 for atom-syntax-bks; Sat, 19 Jul 2003 15:06:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.xaraya.com (xaraya.com [207.44.194.106]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JM6Zqt019787 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 15:06:36 -0700 (PDT) (envelope-from niceguyeddie@xaraya.com) Received: by mail.xaraya.com (Postfix, from userid 1046) id 892F93E00EA; Sat, 19 Jul 2003 22:16:34 +0000 (UTC) Received: from MCNABB (md-wmnsmd-cuda1-c8a-a-99.chvlva.adelphia.net [68.65.108.99]) by mail.xaraya.com (Postfix) with ESMTP id E068B3E00E8 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 22:16:32 +0000 (UTC) Message-ID: <034d01c34e42$2367a930$1202a8c0@MCNABB> From: "J. Cox" <niceguyeddie@xaraya.com> To: <atom-syntax@imc.org> Subject: NNTP Date: Sat, 19 Jul 2003 18:07:25 -0400 Organization: Xaraya X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=0.0 required=5.5 tests=none version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Xaraya's Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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> Hi, Just wondering if there is an NNTP version of this list? If not, I can probably help with some resources, as I am interested in following the development. Thanks! J. Cox http://www.xaraya.com From owner-atom-syntax Sat Jul 19 18:43:29 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6K1hTqt057719 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 18:43:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6K1hSvk057717 for atom-syntax-bks; Sat, 19 Jul 2003 18:43:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vesta.ectoplasm.org (vesta.ectoplasm.org [64.49.222.108]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6K1hRqt057673 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 18:43:27 -0700 (PDT) (envelope-from yining@ectoplasm.org) Received: from [218.5.1.141] (unknown [218.5.1.141]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by vesta.ectoplasm.org (Postfix) with ESMTP id 0EA50A5057 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 20:42:35 -0500 (CDT) Subject: test From: Zhang Yining <yining@ectoplasm.org> To: atom-syntax@imc.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 20 Jul 2003 09:36:32 +0800 Message-Id: <1058665018.6041.24.camel@yining> Mime-Version: 1.0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> how come the emails didn't catch up? From owner-atom-syntax Sat Jul 19 20:36:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6K3abqt076907 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 20:36:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6K3ab84076906 for atom-syntax-bks; Sat, 19 Jul 2003 20:36:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6K3aaqt076901 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 20:36:36 -0700 (PDT) (envelope-from joe@bitworking.org) Received: from bitworking.org (adsl-80-203-24.rdu.bellsouth.net [65.80.203.24]) (authenticated) by scandium.sabren.com (8.11.6/8.11.6) with ESMTP id h6K3eDo24570 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 23:40:13 -0400 Message-ID: <3F1A0E41.9090103@bitworking.org> Date: Sat, 19 Jul 2003 23:36:33 -0400 From: Joe Gregorio <joe@bitworking.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Snapshot feedback References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> In-Reply-To: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Here are my comments on the 2003/07/01 snapshot: http://intertwingly.net/stories/2003/07/01/example.necho 1) feed.subtitle should be optional. 2) entry.content - I think there should be only one, and it should be required, and it may be empty. 3) Drop entry.author.weblog and entry.author.weblog, replace with a single element called entry.author.id. Do the same for entry.contributor. Lastly, a clarification, if an element is noted as being required, can it still be zero length? I ask because entry.title is required and has a note that it may be zero length, making me doubt that the other required elements may be zero length. Thanks, -joe -- http://BitWorking.org http://WellFormedWeb.org From owner-atom-syntax Sun Jul 20 05:30:18 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KCUIqt029025 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 05:30:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KCUIXo029023 for atom-syntax-bks; Sun, 20 Jul 2003 05:30:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.fuzzygroup.net ([65.61.162.22]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6KCUGqt029017 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 05:30:16 -0700 (PDT) (envelope-from scott@feedster.com) Received: (qmail 17507 invoked by uid 82); 20 Jul 2003 07:29:31 -0500 Received: from h002078d4bbaa.ne.client2.attbi.com (HELO advalgo.com) (scott@feedster.com@24.60.137.182) by 65.61.162.22 (qmail 1.03 + ejcp) with SMTP; 20 Jul 2003 07:29:31 -0500 Subject: Re: Snapshot feedback From: "J. Scott Johnson" <scott@feedster.com> Reply-To: scott@feedster.com To: atom-syntax@imc.org In-Reply-To: <3F1A0E41.9090103@bitworking.org> References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1A0E41.9090103@bitworking.org> Content-Type: text/plain Organization: Feedster, Inc. Message-Id: <1058704104.7865.133.camel@devserver01.internal> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 20 Jul 2003 08:28:24 -0400 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> Amen! subtitle needs to be optional. IMHO author needs to be optional. If you have any cases of metasyndication like Feedster, you don't have an author at all generally. And if its required then at least allow 0 length. Scott On Sat, 2003-07-19 at 23:36, Joe Gregorio wrote: > Here are my comments on the 2003/07/01 snapshot: > http://intertwingly.net/stories/2003/07/01/example.necho > > 1) feed.subtitle should be optional. > > 2) entry.content - I think there should be only one, > and it should be required, and it may be empty. > > 3) Drop entry.author.weblog and entry.author.weblog, replace > with a single element called entry.author.id. > Do the same for entry.contributor. > > Lastly, a clarification, if an element is noted as being > required, can it still be zero length? I ask because > entry.title is required and has a note that it may be zero > length, making me doubt that the other required elements may > be zero length. > > Thanks, > -joe -- * * * * * * * * * * * * * * * * * * * J. Scott Johnson, Co-Founder Feedster, LLC Making RSS & Weblogs Searchable web: http://www.feedster.com/ mail: scott@feedster.com im: AIM, Y!: fuzzygroup MSN: fuzzygroup@hotmail.com Jabber: fuzzygroup@jabber.com ICQ: 275649261 * * * * * * * * * * * * * * * * * * * From owner-atom-syntax Sun Jul 20 06:01:01 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KD11qt032924 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 06:01:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KD11h2032923 for atom-syntax-bks; Sun, 20 Jul 2003 06:01:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vsmtp12.tin.it (vsmtp12.tin.it [212.216.176.206]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KD0xqt032762 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 06:01:00 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from trotter (80.182.204.98) by vsmtp12.tin.it (6.7.016) id 3EE0612D00AEF0ED; Sun, 20 Jul 2003 15:00:45 +0200 Reply-To: <danny666@virgilio.it> From: "Danny Ayers" <danny666@virgilio.it> To: <scott@feedster.com>, <atom-syntax@imc.org> Subject: RE: Snapshot feedback Date: Sun, 20 Jul 2003 14:56:08 +0200 Message-ID: <BKELLDAGKABIOCHDFDBPGEKJDGAA.danny666@virgilio.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <1058704104.7865.133.camel@devserver01.internal> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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> > subtitle needs to be optional. +1 > IMHO author needs to be optional. If you have any cases of > metasyndication like Feedster, you don't have an author at all > generally. And if its required then at least allow 0 length. If author is considered more generally like dc:creator or even 'agent', then the metasyndication tool itself can be the author. Having said that, I'm not so sure <author> needs to be a mandatory element. There are other machine sources (like the Gump feed [1]) where the URI of the feed performs a similar role, and probably is all you ever need to know. Whether or not this also should be made explicit alongside the feed contents, so it is preserved in republication...I'm really not sure. What is needed is a way of ensuring that attribution to the original source can *somehow* be maintained as well as possible. I think it would also be desirable to make it easy to include/obtain the chain of republishers (machine or human) that an entry had followed from the source to the current presentation, whatever that may be. Cheers, Danny. [1] http://cvs.apache.org/builds/gump/index.rss From owner-atom-syntax Sun Jul 20 06:02:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KD2nqt033205 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 06:02:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KD2nlS033204 for atom-syntax-bks; Sun, 20 Jul 2003 06:02:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.fuzzygroup.net ([65.61.162.22]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6KD2lqt033195 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 06:02:47 -0700 (PDT) (envelope-from scott@feedster.com) Received: (qmail 18515 invoked by uid 82); 20 Jul 2003 08:02:01 -0500 Received: from h002078d4bbaa.ne.client2.attbi.com (HELO advalgo.com) (scott@feedster.com@24.60.137.182) by 65.61.162.22 (qmail 1.03 + ejcp) with SMTP; 20 Jul 2003 08:02:01 -0500 Subject: RE: Snapshot feedback From: "J. Scott Johnson" <scott@feedster.com> Reply-To: scott@feedster.com To: danny666@virgilio.it Cc: atom-syntax@imc.org In-Reply-To: <BKELLDAGKABIOCHDFDBPGEKJDGAA.danny666@virgilio.it> References: <BKELLDAGKABIOCHDFDBPGEKJDGAA.danny666@virgilio.it> Content-Type: text/plain Organization: Feedster, Inc. Message-Id: <1058706054.7865.169.camel@devserver01.internal> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 20 Jul 2003 09:00:55 -0400 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> Re: If author is considered more generally like dc:creator or even 'agent', then the metasyndication tool itself can be the author. If you have the metasyndication tool being the author then the metasyndication tool gets credit for other people's posts. That feels wrong. Scott On Sun, 2003-07-20 at 08:56, Danny Ayers wrote: > > subtitle needs to be optional. > > +1 > > > IMHO author needs to be optional. If you have any cases of > > metasyndication like Feedster, you don't have an author at all > > generally. And if its required then at least allow 0 length. > > If author is considered more generally like dc:creator or even 'agent', then > the metasyndication tool itself can be the author. > > Having said that, I'm not so sure <author> needs to be a mandatory element. > There are other machine sources (like the Gump feed [1]) where the URI of > the feed performs a similar role, and probably is all you ever need to know. > Whether or not this also should be made explicit alongside the feed > contents, so it is preserved in republication...I'm really not sure. > > What is needed is a way of ensuring that attribution to the original source > can *somehow* be maintained as well as possible. I think it would also be > desirable to make it easy to include/obtain the chain of republishers > (machine or human) that an entry had followed from the source to the current > presentation, whatever that may be. > > Cheers, > Danny. > > [1] http://cvs.apache.org/builds/gump/index.rss -- * * * * * * * * * * * * * * * * * * * J. Scott Johnson, Co-Founder Feedster, LLC Making RSS & Weblogs Searchable web: http://www.feedster.com/ mail: scott@feedster.com im: AIM, Y!: fuzzygroup MSN: fuzzygroup@hotmail.com Jabber: fuzzygroup@jabber.com ICQ: 275649261 * * * * * * * * * * * * * * * * * * * From owner-atom-syntax Sun Jul 20 06:07:40 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KD7eqt034076 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 06:07:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KD7ej2034074 for atom-syntax-bks; Sun, 20 Jul 2003 06:07:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vsmtp3.tin.it (vsmtp3.tin.it [212.216.176.223]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KD7dqt034048 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 06:07:39 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from trotter (80.182.204.98) by vsmtp3.tin.it (7.0.019) id 3F16C22A000C379C; Sun, 20 Jul 2003 15:07:31 +0200 Reply-To: <danny666@virgilio.it> From: "Danny Ayers" <danny666@virgilio.it> To: <scott@feedster.com> Cc: <atom-syntax@imc.org> Subject: RE: Snapshot feedback Date: Sun, 20 Jul 2003 15:02:54 +0200 Message-ID: <BKELLDAGKABIOCHDFDBPAEKKDGAA.danny666@virgilio.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <1058706054.7865.169.camel@devserver01.internal> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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> > If author is considered more generally like dc:creator or even 'agent', > then the metasyndication tool itself can be the author. > > If you have the metasyndication tool being the author then the > metasyndication tool gets credit for other people's posts. That feels > wrong. Good point, that's certainly not desirable at the <entry> level. Do we have anything corresponding to creator of the feed yet? From owner-atom-syntax Sun Jul 20 06:33:19 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KDXJqt037420 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 06:33:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KDXIa1037419 for atom-syntax-bks; Sun, 20 Jul 2003 06:33:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [209.61.183.90]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KDXHqt037413 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 06:33:17 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-066.nc.rr.com [66.57.27.66]) (authenticated) by chromium.sabren.com (8.11.6/8.11.6) with ESMTP id h6KDXNA16048 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 09:33:23 -0400 Message-ID: <3F1A9A09.2080601@intertwingly.net> Date: Sun, 20 Jul 2003 09:32:57 -0400 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Snapshot feedback Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Joe Gregorio wrote: > > Here are my comments on the 2003/07/01 snapshot: > http://intertwingly.net/stories/2003/07/01/example.necho > > 1) feed.subtitle should be optional. In rss 2.0, rss.channel.description is required. Looking at typical usages ("theories of software development", "it's just data"), this appears to be best categorized as a subtitle. > 2) entry.content - I think there should be only one, > and it should be required, and it may be empty. I'd like to wait until the API is flushed out before shutting out this possibility. In particular, it would be nice to see what the consensus is for handling multipart (e.g., text + pictures) entries turns out to be. As for "may be empty", consider that there are multiple types of feeds. Some are summary only. Some provide the full content. Some provide both. > 3) Drop entry.author.weblog and entry.author.weblog, replace > with a single element called entry.author.id. > Do the same for entry.contributor. If you had said entry.author.link, I would have agreed. Why "id"? > Lastly, a clarification, if an element is noted as being > required, can it still be zero length? I ask because > entry.title is required and has a note that it may be zero > length, making me doubt that the other required elements may > be zero length. Title being explicitly zero length was intended to promote the idea of a marker entry which indicated essentially "this space intentionally left blank". I expected pushback in the other direction, but perhaps it is better to have marker elements everywhere. > Thanks, > -joe > From owner-atom-syntax Sun Jul 20 06:53:38 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KDrcqt038727 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 06:53:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KDrbID038726 for atom-syntax-bks; Sun, 20 Jul 2003 06:53:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KDraqt038720 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 06:53:37 -0700 (PDT) (envelope-from joe@bitworking.org) Received: from bitworking.org (adsl-80-203-24.rdu.bellsouth.net [65.80.203.24]) (authenticated) by scandium.sabren.com (8.11.6/8.11.6) with ESMTP id h6KDvFL31615 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 09:57:16 -0400 Message-ID: <3F1A9E8C.6060508@bitworking.org> Date: Sun, 20 Jul 2003 09:52:12 -0400 From: Joe Gregorio <joe@bitworking.org> User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Snapshot feedback References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1A0E41.9090103@bitworking.org> <3F1A324C.5020705@apache.org> In-Reply-To: <3F1A324C.5020705@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Sam Ruby wrote: > Joe Gregorio wrote: > >> 3) Drop entry.author.weblog and entry.author.weblog, replace >> with a single element called entry.author.id. >> Do the same for entry.contributor. > > > I would have been with you had you said entry.author.link. Why are > you suggesting an id? entry.author.link is fine, I am not tied to a particular name, I just believe there should be a single URI that identifies the author. One downfall of .weblog and .homepage is that it seems to imply that the author is a person, when in fact the author could be an organization or an automated tool. -joe From owner-atom-syntax Sun Jul 20 07:09:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KE99qt039100 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 07:09:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KE99Tb039091 for atom-syntax-bks; Sun, 20 Jul 2003 07:09:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KE94qt039055 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 07:09:05 -0700 (PDT) (envelope-from joe@bitworking.org) Received: from bitworking.org (adsl-80-203-24.rdu.bellsouth.net [65.80.203.24]) (authenticated) by scandium.sabren.com (8.11.6/8.11.6) with ESMTP id h6KECiL32304 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 10:12:44 -0400 Message-ID: <3F1AA22C.10709@bitworking.org> Date: Sun, 20 Jul 2003 10:07:40 -0400 From: Joe Gregorio <joe@bitworking.org> User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Snapshot feedback (multiple content elements) References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1A0E41.9090103@bitworking.org> <3F1A324C.5020705@apache.org> In-Reply-To: <3F1A324C.5020705@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Sam Ruby wrote: > As far as only one content element per entry goes, I've seen this > brought up a number of times. One thing I would like to see before > this is settled is some more experience with usage as an API. In > particular, I'm interested in multipart blog entries (text plus > pictures). If no compelling need emerges from this, I would agree > that having at most one (or perhaps exactly one) would be simpler. Agreed, more experience with an API would be preferred before changing this. -joe From owner-atom-syntax Sun Jul 20 07:47:40 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KEleqt040397 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 07:47:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KEleDS040396 for atom-syntax-bks; Sun, 20 Jul 2003 07:47:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from localhost.localdomain (CPE-65-30-234-116.mn.rr.com [65.30.234.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KEldqt040391 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 07:47:39 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h6KEp5lg005004 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 09:51:05 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h6KEp5iA005000; Sun, 20 Jul 2003 09:51:05 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: atom-syntax@imc.org Subject: Re: Snapshot feedback References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1A0E41.9090103@bitworking.org> <3F1A324C.5020705@apache.org> <3F1A9E8C.6060508@bitworking.org> From: Ken MacLeod <ken@bitsko.slc.ut.us> Date: 20 Jul 2003 09:51:05 -0500 In-Reply-To: <3F1A9E8C.6060508@bitworking.org> Message-ID: <m3r84l8d5y.fsf@bitsko.slc.ut.us> Lines: 46 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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> Joe Gregorio <joe@bitworking.org> writes: > Sam Ruby wrote: > > > Joe Gregorio wrote: > > > >> 3) Drop entry.author.weblog and entry.author.weblog, replace > >> with a single element called entry.author.id. > >> Do the same for entry.contributor. > > > > I would have been with you had you said entry.author.link. Why > > are you suggesting an id? > > entry.author.link is fine, I am not tied to a particular name, I > just believe there should be a single URI that identifies the > author. For interoperability with RDF, it would be great if any element considered an "entity" have an optional <id> that was the unique URI for that entity. The author case actually ends up being an exception! The RDF folks (and mostly driven by the FOAF folks in particular, who work with this every day) have come to the general conclusion that no one really can come up with a workable URI scheme for "people". Therefore, they recommend foaf:Person *not* have a subject URI and queries be made on otherwise unique properties, such as 'mbox' and, for the spam-blocking challenged, 'mbox_sha1sum' (the latter being just a one-way hash of 'mbox' to prevent email address harvesting). > One downfall of .weblog and .homepage is that it seems to imply that > the author is a person, when in fact the author could be an > organization or an automated tool. Organizations and systems can have weblogs and homepages, too. Occasionally, "weblog" isn't accurate as there is no person specifically selecting the entries to display, but it's still an ordered collection of resources presented day-to-day. Following in the footsteps of the FOAF folks though, none of weblog, homepage, email address, or other property be considered a canonical "id" of that person, organization, or system. You can't just "pick one" and have it make sense as an id in the conceptual model of an author. -- Ken From owner-atom-syntax Sun Jul 20 09:41:20 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KGfKqt045491 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 09:41:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KGfKaN045489 for atom-syntax-bks; Sun, 20 Jul 2003 09:41:20 -0700 (PDT) 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.9/8.12.8) with ESMTP id h6KGfJqt045471 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 09:41:19 -0700 (PDT) (envelope-from jeffreywinter@comcast.net) Received: from winter (h00c04fa0fd63.ne.client2.attbi.com[65.96.172.188](untrusted sender)) by comcast.net (sccrmhc12) with SMTP id <200307201641150120057sl7e>; Sun, 20 Jul 2003 16:41:15 +0000 Message-ID: <002c01c34edd$3fc48ad0$6401a8c0@winter> From: "Jeffrey Winter" <jeffreywinter@comcast.net> To: <atom-syntax@imc.org> References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1A0E41.9090103@bitworking.org> Subject: Re: Snapshot feedback Date: Sun, 20 Jul 2003 12:37:45 -0400 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.3790.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Where do things stand with Comments? Will comments be nested; referenced as shown here: http://www.intertwingly.net/wiki/pie/CommentEntryExample ; or is this still open for debate? Thanks, - Jeff From owner-atom-syntax Sun Jul 20 12:05:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KJ5Yqt059899 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 12:05:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KJ5Y14059898 for atom-syntax-bks; Sun, 20 Jul 2003 12:05:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vsmtp12.tin.it (vsmtp12.tin.it [212.216.176.206]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KJ5Sqt059880 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 12:05:33 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from trotter (80.182.204.42) by vsmtp12.tin.it (6.7.016) id 3EE0612D00AFB1BC; Sun, 20 Jul 2003 21:05:13 +0200 Reply-To: <danny666@virgilio.it> From: "Danny Ayers" <danny666@virgilio.it> To: "Jeffrey Winter" <jeffreywinter@comcast.net>, <atom-syntax@imc.org> Subject: RE: Snapshot feedback Date: Sun, 20 Jul 2003 21:00:37 +0200 Message-ID: <BKELLDAGKABIOCHDFDBPGELCDGAA.danny666@virgilio.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <002c01c34edd$3fc48ad0$6401a8c0@winter> 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> > Where do things stand with Comments? Will comments be nested; > referenced as shown here: > > http://www.intertwingly.net/wiki/pie/CommentEntryExample > > ; or is this still open for debate? I hope it's still open for debate, especially in respect of nested comments if that is expected to go beyond a simple entry-->comments relationship. The structure of comments is just a single aspect of the larger issue of message threading, which IMHO goes way beyond the scope of Atom. Myself and others have looked into this in the context of ThreadsML [1]. If nesting is used for the expression of thread structure, then it is hobbled from the word go - how for example do you represent a comment that summarizes two separate threads? Personally I think it would be better to keep threading (beyond 1:n, entry:comments) away from the core of Atom, though I imagine that it will be one of the early extensions. Cheers, Danny. [1] http://www.quicktopic.com/cgi-bin/thwiki.pl?ThreadsML From owner-atom-syntax Sun Jul 20 12:36:13 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KJaDqt061269 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 12:36:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KJaDxo061268 for atom-syntax-bks; Sun, 20 Jul 2003 12:36:13 -0700 (PDT) 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.9/8.12.8) with ESMTP id h6KJaBqt061263 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 12:36:11 -0700 (PDT) (envelope-from solitude@vkps.co.uk) Received: from modem-1424.baboon.dialup.pol.co.uk ([81.78.21.144] helo=vkps.co.uk) by cmailg2.svr.pol.co.uk with esmtp (Exim 4.14) id 19eJyb-0003HY-DS; Sun, 20 Jul 2003 20:36:09 +0100 Message-ID: <3F1AEF2B.1060906@vkps.co.uk> Date: Sun, 20 Jul 2003 20:36:11 +0100 From: Gary F <solitude@vkps.co.uk> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030616 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby <rubys@intertwingly.net> CC: atom-syntax@imc.org Subject: Re: Snapshot feedback References: <3F1A9A09.2080601@intertwingly.net> In-Reply-To: <3F1A9A09.2080601@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Sam Ruby wrote: > > Joe Gregorio wrote: > >> >> 1) feed.subtitle should be optional. > > > In rss 2.0, rss.channel.description is required. Looking at typical > usages ("theories of software development", "it's just data"), this > appears to be best categorized as a subtitle. > Does anyone read the wiki? We reached consensus on the example page that subtitle should be pulled since we already had summary which does exactly what description does. We agreed to keep one or the other, but not both. Subtitle lost. To catch up, read http://www.intertwingly.net/wiki/pie/SubTitle . It has been linked to from the EchoExample page (where the argument originally occurred) for weeks now. From owner-atom-syntax Sun Jul 20 13:01:25 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KK1Pqt061665 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 13:01:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KK1PNs061664 for atom-syntax-bks; Sun, 20 Jul 2003 13:01:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KK1Oqt061659 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 13:01:24 -0700 (PDT) (envelope-from jjulian2@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h6KK1QqS013512 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 13:01:26 -0700 (PDT) Received: from CompaqLaptop (adsl-66-143-44-20.dsl.ksc2mo.swbell.net [66.143.44.20]) (authenticated bits=0) by mac.com (Xserve/8.12.9/MantshX 2.0) with ESMTP id h6KK1N9d017227 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 13:01:24 -0700 (PDT) Message-Id: <200307202001.h6KK1N9d017227@mac.com> From: "Jeff Julian" <jjulian2@mac.com> To: <atom-syntax@imc.org> Subject: RE: Snapshot feedback Date: Sun, 20 Jul 2003 15:01: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.5329 In-reply-to: <BKELLDAGKABIOCHDFDBPGELCDGAA.danny666@virgilio.it> Thread-Index: AcNO8j0PSFr+OmvFTg+0qbLyTpMItAABr7BQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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> I personally like the idea of nested comments. I think Atom feeds should be easily transformable into the actual blog site itself. My blogging tool, geekswithblogs.com uses the RSS feed with additional nodes, like comments and link categories to build the output site with simple XSLT transforms. http://jjulian.geekswithblogs.com/BlogFeed.aspx is the feed I use to build the site. I would love to see Atom have a similar format. Jeff Julian -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Danny Ayers Sent: Sunday, July 20, 2003 2:01 PM To: Jeffrey Winter; atom-syntax@imc.org Subject: RE: Snapshot feedback > Where do things stand with Comments? Will comments be nested; > referenced as shown here: > > http://www.intertwingly.net/wiki/pie/CommentEntryExample > > ; or is this still open for debate? I hope it's still open for debate, especially in respect of nested comments if that is expected to go beyond a simple entry-->comments relationship. The structure of comments is just a single aspect of the larger issue of message threading, which IMHO goes way beyond the scope of Atom. Myself and others have looked into this in the context of ThreadsML [1]. If nesting is used for the expression of thread structure, then it is hobbled from the word go - how for example do you represent a comment that summarizes two separate threads? Personally I think it would be better to keep threading (beyond 1:n, entry:comments) away from the core of Atom, though I imagine that it will be one of the early extensions. Cheers, Danny. [1] http://www.quicktopic.com/cgi-bin/thwiki.pl?ThreadsML From owner-atom-syntax Sun Jul 20 13:13:29 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KKDTqt062568 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 13:13:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KKDS7K062567 for atom-syntax-bks; Sun, 20 Jul 2003 13:13:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [209.61.183.90]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KKDPqt062558 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 13:13:25 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-066.nc.rr.com [66.57.27.66]) (authenticated) by chromium.sabren.com (8.11.6/8.11.6) with ESMTP id h6KKDVq05001; Sun, 20 Jul 2003 16:13:31 -0400 Message-ID: <3F1AF7CC.9020304@intertwingly.net> Date: Sun, 20 Jul 2003 16:13:00 -0400 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary F <solitude@vkps.co.uk> CC: atom-syntax@imc.org Subject: Re: Snapshot feedback References: <3F1A9A09.2080601@intertwingly.net> <3F1AEF2B.1060906@vkps.co.uk> In-Reply-To: <3F1AEF2B.1060906@vkps.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Gary F wrote: > > Does anyone read the wiki? We reached consensus on the example page that > subtitle should be pulled since we already had summary which does > exactly what description does. We agreed to keep one or the other, but > not both. Subtitle lost. To catch up, read > http://www.intertwingly.net/wiki/pie/SubTitle . > > It has been linked to from the EchoExample page (where the argument > originally occurred) for weeks now. I, for one, would like to see a change log from the 0.1 snapshot. I'm quite willing to produce one, or it could be produced collaboratively. Here's my thoughts on the current example: Feed summary works for me. (I'd prefer subtitle, but ...) Feed modified appears to be gone. At the moment, it appears that author is outside of the entry, which would be problematic for my comment feeds. Contributor is missing. This is supposed to be a 'maximal' feed? A <url> element inside of <author> seems to have replaced <homepage> and <weblog>. <link> would seem to me to be more consistent. Entry id is now an attribute. I'd still prefer a URI. Subtitle is gone from entry. I'm OK with that. Issued is UTC. Sigh. There seems to be a summary inside the entry and inside the first content. Seems redundant. From an xml point of view, mode=escaped and mode=cdata seems redundant. The body in the html example is in the wrong namespace? - Sam Ruby From owner-atom-syntax Sun Jul 20 14:26:44 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KLQiqt069835 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 14:26:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KLQiUc069834 for atom-syntax-bks; Sun, 20 Jul 2003 14:26:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KLQgqt069828 for <atom-syntax@above.proper.com>; Sun, 20 Jul 2003 14:26:43 -0700 (PDT) (envelope-from doug@sonosphere.com) Received: from h-69-3-26-2.snvacaid.covad.net ([69.3.26.2] helo=sonosphere.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19eLhc-0002tA-00 for atom-syntax@above.proper.com; Sun, 20 Jul 2003 14:26:44 -0700 Date: Sun, 20 Jul 2003 14:26:43 -0700 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: snapshot feedback From: Doug Wyatt <doug@sonosphere.com> To: atom-syntax@above.proper.com Content-Transfer-Encoding: 7bit Message-Id: <DBAD9BF4-BAF8-11D7-A7C7-000393A34B5A@sonosphere.com> X-Mailer: Apple Mail (2.552) 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> I hacked together a prototype feed in my custom system: http://www.sonosphere.com/atom.xml I think I was copying from Mark Pilgrim's example as well as the 1.0 snapshot. To elaborate on the unresolved issues I list in a comment at the top of the feed: - <description> makes a lot more sense than <subtitle>. Something for the user to see in an aggregator when trying to decide whether to browse a new feed. - should there be <language> at the feed level? (and more than 1 of them for multilingual feeds?) The RSS 2.0 spec explains that this may be useful for aggregators, to allow the user to search for feeds only in a certain language - having a feed-level <author> seems like a step towards solving both the problem of aggregator-as-author and redundant (and a bit verbose) per-entry <author>s in a single-author feed. - having a feed-level <copyright> seems desirable - (dates, subjects - just notes to myself to do this) The biggest implementation issue, from my POV, is how to treat URL's in HTML embedded in <content>. In my prototype, all the local URL's are absolute paths from the top of my site -- which is not the same as the <feed>/<link>. XIST (the toolkit I'm using) may actually make it relatively painless to transform them into absolute URL's, but it seems simpler all around to have a base URL on the feed -- HTML renderers must have a concept of a base URL, so why not save the generator the trouble of not being able to put one in the feed? Doug From owner-atom-syntax Sun Jul 20 14:36:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KLanqt070188 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 14:36:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KLam1b070185 for atom-syntax-bks; Sun, 20 Jul 2003 14:36:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from localhost.localdomain (CPE-65-30-234-116.mn.rr.com [65.30.234.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KLakqt070180 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 14:36:46 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h6KLeJlg007219 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 16:40:19 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h6KLeJt2007215; Sun, 20 Jul 2003 16:40:19 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: <atom-syntax@imc.org> Subject: Re: Snapshot feedback References: <BKELLDAGKABIOCHDFDBPGELCDGAA.danny666@virgilio.it> From: Ken MacLeod <ken@bitsko.slc.ut.us> Date: 20 Jul 2003 16:40:19 -0500 In-Reply-To: <BKELLDAGKABIOCHDFDBPGELCDGAA.danny666@virgilio.it> Message-ID: <m3n0f898sc.fsf@bitsko.slc.ut.us> Lines: 68 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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> "Danny Ayers" <danny666@virgilio.it> writes: > > Where do things stand with Comments? Will comments be nested; > > referenced as shown here: > > > > http://www.intertwingly.net/wiki/pie/CommentEntryExample > The structure of comments is just a single aspect of the larger > issue of message threading, which IMHO goes way beyond the scope of > Atom. Myself and others have looked into this in the context of > ThreadsML [1]. If nesting is used for the expression of thread > structure, then it is hobbled from the word go - how for example do > you represent a comment that summarizes two separate threads? I've been working on a sample RESTful server[2] and am in the process of adding comment support to it, to show POST and GET-queries. One current practice using RSS is to use an RSS channel per weblog item to hold a comment feed. That could use a threading model but I'm not convinced a "feed" is the right way to model comments. An alternative, that I'm sketching out in the sample server, is modeled as a query "what are all the references you have to this URI?", where URI can be the entry, or it can be the weblog, a story, audio, photos, or other resources at the site. References could include other entries, comments, trackbacks, referrers, known directory listings, etc. A similar query returning the same type of results could also be sent to a search site like Technorati or a third-party annotation server, and a reader would then have a union of all the references. The result set would use a highly constrained (minimal data) profile of Atom entities and allow entities from third parties (in their own namespaces): <references xmlns="http://example.com/atom/ns#" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:daypop="http://www.daypop.com/ns#" xmlns:threads="http://purl.org/threads"> <comment> <link>http://bitsko.slc.ut.us/~ken/atom.cgi/comments/restful-1.atom</link> <title>RESTful comment

From owner-atom-syntax Thu Jul 17 12:38:27 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HJcRqt020120 for ; Thu, 17 Jul 2003 12:38:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6HJcRRI020119 for atom-syntax-bks; Thu, 17 Jul 2003 12:38:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from localhost.localdomain (CPE-65-30-234-116.mn.rr.com [65.30.234.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HJcQqt020113 for ; Thu, 17 Jul 2003 12:38:26 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h6HJetlg007993 for ; Thu, 17 Jul 2003 14:40:55 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h6HJesBi007989; Thu, 17 Jul 2003 14:40:55 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: atom-syntax@imc.org Subject: Syntax pattern From: Ken MacLeod Date: 17 Jul 2003 14:40:54 -0500 Message-ID: Lines: 46 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 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: I added the following to the Introduction in the Syntax document, under "Schema Patterns": > The syntax follows certain repeating patterns: > > * "Entity" elements form the "top-level" elements, which can > sometimes be contained in other entity elements. Examples of > Atom entities would be , , , , and > (complete set to be determined). > > * "Property" elements are direct children of their entity > elements. Examples of property elements would be , > <summary>, <link>, <content>, etc. > > * Property and entity elements are all fully qualified, either > in the core Atom namespace or an extension namespace. Examples > usually show elements in the Atom namespace using a default > namespace on the root entity element. > > * <content> and content-like elements (title, subtitle, and > summary) have an associated a MIME type, mode of encoding, > language, and either a value inline or through a URI > reference. A <content> element may have a relation that > indicates whether the content is an excerpt, preview, thumbnail, > or otherwise not the entire content. I thought it would be a good inaugural message to the list, to start with a general discussion as to the style or pattern to the schema rather than jumping straight to individual element-content models. As always, these are not cast in stone. There is still discussion in EscapedHtmlContent about what <content> may hold (is it limited to just *ML, or should *ML types be special-cased). There is discussion in ContentProblems regarding the distinction between whole and partial entities. ContentDiscussion appears to have a simple majority preferring only one <content>, but current examples are multiple-contents with an undefined model for selecting a representation. The utility of <content src='...'> appears to be in question, but if it is useful, is a MIME multipart wrapper not far behind (a la SOAP with Attachments)? Since the decision was made to specify model and syntax in one document (SyntaxConsiderations), I presume this list covers both? -- Ken From owner-atom-syntax Thu Jul 17 15:48:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HMmbqt032282 for <atom-syntax-bks@above.proper.com>; Thu, 17 Jul 2003 15:48:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6HMmb8n032281 for atom-syntax-bks; Thu, 17 Jul 2003 15:48:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HMmZqt032274 for <atom-syntax@above.proper.com>; Thu, 17 Jul 2003 15:48:35 -0700 (PDT) (envelope-from tbray@textuality.com) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id 373D21031B for <atom-syntax@above.proper.com>; Thu, 17 Jul 2003 15:48:38 -0700 (PDT) Message-ID: <3F1727C6.3080102@textuality.com> Date: Thu, 17 Jul 2003 15:48:38 -0700 From: Tim Bray <tbray@textuality.com> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@above.proper.com Subject: Testing Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> 1 2 3 -- Cheers, Tim Bray (ongoing fragmented essay: http://www.tbray.org/ongoing/) From owner-atom-syntax Fri Jul 18 13:53:52 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IKrqqt021496 for <atom-syntax-bks@above.proper.com>; Fri, 18 Jul 2003 13:53:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6IKrqM3021494 for atom-syntax-bks; Fri, 18 Jul 2003 13:53:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IKrpqt021488 for <atom-syntax@imc.org>; Fri, 18 Jul 2003 13:53:51 -0700 (PDT) (envelope-from joe@bitworking.org) Received: from bitworking.org (198-143-226-158.dsl.btitelecom.net [198.143.226.158]) (authenticated) by scandium.sabren.com (8.11.6/8.11.6) with ESMTP id h6IKvDO07834 for <atom-syntax@imc.org>; Fri, 18 Jul 2003 16:57:13 -0400 Message-ID: <3F185F8A.3060208@bitworking.org> Date: Fri, 18 Jul 2003 16:58:50 -0400 From: Joe Gregorio <joe@bitworking.org> User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Testing References: <200307161333.h6GDXb4b082599@above.proper.com> In-Reply-To: <200307161333.h6GDXb4b082599@above.proper.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: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Testing From owner-atom-syntax Fri Jul 18 18:44:47 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6J1ilqt035926 for <atom-syntax-bks@above.proper.com>; Fri, 18 Jul 2003 18:44:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6J1ilI1035925 for atom-syntax-bks; Fri, 18 Jul 2003 18:44:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6J1ikqt035920 for <atom-syntax@imc.org>; Fri, 18 Jul 2003 18:44:46 -0700 (PDT) (envelope-from joe@bitworking.org) Received: from bitworking.org (adsl-80-203-24.rdu.bellsouth.net [65.80.203.24]) (authenticated) by scandium.sabren.com (8.11.6/8.11.6) with ESMTP id h6J1m6D21311 for <atom-syntax@imc.org>; Fri, 18 Jul 2003 21:48:06 -0400 Message-ID: <3F18A287.1000209@bitworking.org> Date: Fri, 18 Jul 2003 21:44:39 -0400 From: Joe Gregorio <joe@bitworking.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Test Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Testing. From owner-atom-syntax Sat Jul 19 05:12:51 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JCCpqt087247 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 05:12:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JCCpYT087246 for atom-syntax-bks; Sat, 19 Jul 2003 05:12:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vsmtp3.tin.it (vsmtp3.tin.it [212.216.176.223]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JCCoqt087240 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 05:12:50 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from trotter (80.182.204.218) by vsmtp3.tin.it (7.0.019) id 3F16C22A000931E1 for atom-syntax@imc.org; Sat, 19 Jul 2003 14:12:50 +0200 Reply-To: <danny666@virgilio.it> From: "Danny Ayers" <danny666@virgilio.it> To: <atom-syntax@imc.org> Subject: Extension mechanism Date: Sat, 19 Jul 2003 14:08:16 +0200 Message-ID: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal 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> Hi folks, Great to see the list. One thing about the syntax that concerns me greatly is that there doesn't yet appear to be a consistent way of interpreting material from other namespaces. I believe this to be a make or break issue for interop. Such a mechanism is also lacking from RSS 2.0, which relies on extension modules to define how they are to be used. This approach is IMHO totally inadequate, the main reason be that it is likely to lead to inconsistency in the way external data has to be handled by an Atom processor. This will make coding harder. The issue was however thoroughly covered in RSS 1.0 thanks to RDF/XML. I doubt very much that the richness of the full RDF graph is needed inside Atom, but I think it will be desirable to be able to extend into or attach a full graph if required. In fact, another justification for a sound extension mechanism is to be able to interoperate with RSS 1.0 and other RDF data. It has been suggested that "ignore anything you don't recognise" might be a suitable mechanism, but I believe this has two major flaws : the parts that aren't recognised may alter the meaning of other parts of the feed (e.g. a Creative Commons license, or a element saying "this is all a joke"), so their total omission may have side effects; valuable data is being thrown away (compare the RDF approach). A start has been made on defining extension modules on the Wiki [1], but as yet there doesn't seem to be anything substantial. I believe that such a mechanism can be defined without any impact on the work that has been done so far. All I think that is needed in the core is a means of saying whether an included element from another namespace is additional content, *or* is additional information about its parent. I've put a strawman on the Wiki [2], in brief : 1. Any elements outside of the Atom namespace within a <metadata> element will be interpreted as being about the parent element. 2. Any other elements outside of the Atom namespace will be interpreted as secondary content associated with their parent element. The use of a <metadata> element has prior art in SVG [3], where it seems to work quite well. Cheers, Danny. [1] http://www.intertwingly.net/wiki/pie/ExtensionModule [2] http://www.intertwingly.net/wiki/pie/SyntaxExtensionMechanism [3] http://www.w3.org/TR/SVG/metadata.html ---- http://dannyayers.com From owner-atom-syntax Sat Jul 19 06:05:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JD59qt090497 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 06:05:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JD59kh090495 for atom-syntax-bks; Sat, 19 Jul 2003 06:05:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [209.61.183.90]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JD57qt090486 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 06:05:07 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-066.nc.rr.com [66.57.27.66]) (authenticated) by chromium.sabren.com (8.11.6/8.11.6) with ESMTP id h6JD5Bn11118 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 09:05:12 -0400 Message-ID: <3F1941E7.4000901@intertwingly.net> Date: Sat, 19 Jul 2003 09:04:39 -0400 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Extension mechanism References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> In-Reply-To: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Danny Ayers wrote: > > I believe that such a mechanism can be defined without any impact on the > work that has been done so far. All I think that is needed in the core is a > means of saying whether an included element from another namespace is > additional content, *or* is additional information about its parent. I've > put a strawman on the Wiki [2] WOW. Orthogonal Extensibility. Love it. Contrast: <Envelope> <Header>  </Header> <Body> <entry>  </entry> </Body> </Envelope> With: <entry>  <metadata>  </metadata> </entry> A few points: * metadata is actually a matter of perspective. Is the issued date content or metadata? If LiveJournal wants to capture the mood of the person while composing this entry, is that additional content or additional information about the entry? * if we go down this path, it would be worth having something analagous to the 'mustUnderstand' attribute as defined in the SOAP specification. - Sam Ruby From owner-atom-syntax Sat Jul 19 06:04:08 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JD48qt090343 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 06:04:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JD4818090341 for atom-syntax-bks; Sat, 19 Jul 2003 06:04:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (law12-oe49.law12.hotmail.com [64.4.18.21]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JD46qt090323 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 06:04:06 -0700 (PDT) (envelope-from wkearney99@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 19 Jul 2003 06:04:02 -0700 Received: from 66.92.145.79 by law12-oe49.law12.hotmail.com with DAV; Sat, 19 Jul 2003 13:04:02 +0000 X-Originating-IP: [66.92.145.79] X-Originating-Email: [wkearney99@hotmail.com] Reply-To: "Bill Kearney" <wkearney99@hotmail.com> From: "Bill Kearney" <wkearney99@hotmail.com> To: <atom-syntax@imc.org> References: <3F18A287.1000209@bitworking.org> Subject: Re: Test Date: Sat, 19 Jul 2003 09:04:01 -0400 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 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Message-ID: <Law12-OE494lB4BwOZx0000d699@hotmail.com> X-OriginalArrivalTime: 19 Jul 2003 13:04:02.0586 (UTC) FILETIME=[39F077A0:01C34DF6] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> 1... 2... 3... ----- Original Message ----- From: "Joe Gregorio" <joe@bitworking.org> To: <atom-syntax@imc.org> Sent: Friday, July 18, 2003 9:44 PM Subject: Test > > Testing. > > From owner-atom-syntax Sat Jul 19 06:34:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JDYnqt095870 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 06:34:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JDYnYN095869 for atom-syntax-bks; Sat, 19 Jul 2003 06:34:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (law12-oe64.law12.hotmail.com [64.4.18.199]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JDYlqt095837 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 06:34:48 -0700 (PDT) (envelope-from wkearney99@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 19 Jul 2003 06:34:38 -0700 Received: from 66.92.145.79 by oe64.adinternal.hotmail.com with DAV; Sat, 19 Jul 2003 13:34:38 +0000 X-Originating-IP: [66.92.145.79] X-Originating-Email: [wkearney99@hotmail.com] Reply-To: "Bill Kearney" <wkearney99@hotmail.com> From: "Bill Kearney" <wkearney99@hotmail.com> To: "atom-syntax" <atom-syntax@imc.org> References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1941E7.4000901@intertwingly.net> Subject: prefixing mailing list messages? Date: Sat, 19 Jul 2003 09:34:43 -0400 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 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Message-ID: <LAW12-OE649yfB4mvo9000053d5@hotmail.com> X-OriginalArrivalTime: 19 Jul 2003 13:34:38.0843 (UTC) FILETIME=[806F0CB0:01C34DFA] 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> Can we had the [atom-syntax] prefix prefixed in the subject line of messages from the mailing list? It makes sorting the out in the inbox a bit easier. And no, header lines don't really help. Thanks, -Bill Kearney From owner-atom-syntax Sat Jul 19 07:08:14 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JE8Eqt098215 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 07:08:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JE8EXp098214 for atom-syntax-bks; Sat, 19 Jul 2003 07:08:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta2-svc.business.ntl.com (mta2-svc.business.ntl.com [62.253.164.42]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JE8Bqt098204 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 07:08:12 -0700 (PDT) (envelope-from nick@willow.frejol.org) Received: from willow.frejol.org ([80.1.28.119]) by mta2-svc.business.ntl.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20030719140810.RBP18309.mta2-svc.business.ntl.com@willow.frejol.org> for <atom-syntax@imc.org>; Sat, 19 Jul 2003 15:08:10 +0100 Message-ID: <3F1950C9.2040107@willow.frejol.org> Date: Sat, 19 Jul 2003 15:08:09 +0100 From: Nick Boalch <nick@willow.frejol.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030701 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: prefixing mailing list messages? References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1941E7.4000901@intertwingly.net> <LAW12-OE649yfB4mvo9000053d5@hotmail.com> In-Reply-To: <LAW12-OE649yfB4mvo9000053d5@hotmail.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: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Bill Kearney wrote: > Can we had the [atom-syntax] prefix prefixed in the subject line of messages > from the mailing list? While we're doing issues with the list mechanics (atom-syntax-syntax? :) is there any chance of having Mail-Followup-To: set appropriately by the list software? Cheers, N. -- Nick Boalch <URL:http://nick.frejol.org/> From owner-atom-syntax Sat Jul 19 07:18:39 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JEIdqt098393 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 07:18:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JEIdCu098389 for atom-syntax-bks; Sat, 19 Jul 2003 07:18:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (law12-oe22.law12.hotmail.com [64.4.18.79]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JEIbqt098382 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 07:18:38 -0700 (PDT) (envelope-from wkearney99@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 19 Jul 2003 07:18:33 -0700 Received: from 66.92.145.79 by law12-oe22.law12.hotmail.com with DAV; Sat, 19 Jul 2003 14:18:33 +0000 X-Originating-IP: [66.92.145.79] X-Originating-Email: [wkearney99@hotmail.com] Reply-To: "Bill Kearney" <wkearney99@hotmail.com> From: "Bill Kearney" <wkearney99@hotmail.com> To: <atom-syntax@imc.org> References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1941E7.4000901@intertwingly.net> <LAW12-OE649yfB4mvo9000053d5@hotmail.com> <3F1950C9.2040107@willow.frejol.org> Subject: Re: prefixing mailing list messages? Date: Sat, 19 Jul 2003 10:18:33 -0400 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 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Message-ID: <Law12-OE22dmXYJrOOO0000df4d@hotmail.com> X-OriginalArrivalTime: 19 Jul 2003 14:18:33.0990 (UTC) FILETIME=[A31A9260:01C34E00] 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> This is an OLD argument. Some folks strongly disagree with this idea. I greatly prefer reply-to being the list and support Nick's suggestion. It also avoids the insane reply-to-all hassles of the thread particpants getting two copies. Yes, mail client software can be used to work around it. But most MUAs do a bad job of this. -Bill Kearney ----- Original Message ----- From: "Nick Boalch" <nick@willow.frejol.org> To: <atom-syntax@imc.org> Sent: Saturday, July 19, 2003 10:08 AM Subject: Re: prefixing mailing list messages? > > Bill Kearney wrote: > > Can we had the [atom-syntax] prefix prefixed in the subject line of messages > > from the mailing list? > > While we're doing issues with the list mechanics (atom-syntax-syntax? :) > is there any chance of having Mail-Followup-To: set appropriately by the > list software? From owner-atom-syntax Sat Jul 19 07:18:40 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JEIeqt098396 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 07:18:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JEIeBL098395 for atom-syntax-bks; Sat, 19 Jul 2003 07:18:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta2-svc.business.ntl.com (mta2-svc.business.ntl.com [62.253.164.42]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JEIcqt098387 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 07:18:39 -0700 (PDT) (envelope-from nick@willow.frejol.org) Received: from willow.frejol.org ([80.1.28.119]) by mta2-svc.business.ntl.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20030719141838.YNW18309.mta2-svc.business.ntl.com@willow.frejol.org> for <atom-syntax@imc.org>; Sat, 19 Jul 2003 15:18:38 +0100 Message-ID: <3F19533D.3050509@willow.frejol.org> Date: Sat, 19 Jul 2003 15:18:37 +0100 From: Nick Boalch <nick@willow.frejol.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030701 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Extension mechanism References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1941E7.4000901@intertwingly.net> In-Reply-To: <3F1941E7.4000901@intertwingly.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: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Sam Ruby wrote: > metadata is actually a matter of perspective. Is the issued date > content or metadata? To my mind, the issued date is definitely metadata -- particularly as our projected format supports various different kinds of date metadata about a given entry (created, issued, modified, &c, &c). > If LiveJournal wants to capture the mood of the person while composing > this entry, is that additional content or additional information about > the entry? This one's more ambiguous. I'd call it as additional content, I think, purely on the basis of safe generalisation. Sure, in many cases such information could arguably be considered metadata, but I reckon I can project a number of examples where 'mood' isn't a useful piece of additional information about an entry. Cheers, N. -- Nick Boalch <URL:http://nick.frejol.org/> From owner-atom-syntax Sat Jul 19 07:56:57 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JEuvqt099094 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 07:56:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JEuvpB099093 for atom-syntax-bks; Sat, 19 Jul 2003 07:56:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vsmtp12.tin.it (vsmtp12.tin.it [212.216.176.206]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JEuuqt099081 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 07:56:56 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from trotter (80.182.209.190) by vsmtp12.tin.it (6.7.016) id 3EE0612D00AD5B30; Sat, 19 Jul 2003 16:56:30 +0200 Reply-To: <danny666@virgilio.it> From: "Danny Ayers" <danny666@virgilio.it> To: "Sam Ruby" <rubys@intertwingly.net>, <atom-syntax@imc.org> Subject: RE: Extension mechanism Date: Sat, 19 Jul 2003 16:51:55 +0200 Message-ID: <BKELLDAGKABIOCHDFDBPMEIODGAA.danny666@virgilio.it> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3F1941E7.4000901@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> > Contrast: > > <Envelope> > <Header> >  > </Header> > <Body> > <entry> >  > </entry> > </Body> > </Envelope> > > With: > > <entry> >  > <metadata> >  > </metadata> > </entry> A very interesting comparison! > A few points: > > * metadata is actually a matter of perspective. Is the issued date > content or metadata? If LiveJournal wants to capture the mood of the > person while composing this entry, is that additional content or > additional information about the entry? That's true, the content/meta divide is quite artificial (the same applies with the head/body approach). My thinking behind interpreting the (kind of) default inclusion as content is that a newsreader could just display it without thinking, whereas the <metadata> wrapper would be a big hint that perhaps this shouldn't simply be rendered in the viewer directly. I could be wrong, but it feels like this approach may make life easier at either end, and doesn't interfere with the rest of the syntax. > * if we go down this path, it would be worth having something analagous > to the 'mustUnderstand' attribute as defined in the SOAP specification. That sounds a very promising way of dealing with extensions that might say things like "not for republication". Cheers, Danny. From owner-atom-syntax Sat Jul 19 08:07:59 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JF7xqt099260 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 08:07:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JF7xQH099259 for atom-syntax-bks; Sat, 19 Jul 2003 08:07:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JF7wqt099254 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 08:07:58 -0700 (PDT) (envelope-from tbray@textuality.com) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id 7C3AF1032A; Sat, 19 Jul 2003 08:07:59 -0700 (PDT) Message-ID: <3F195ECD.3000102@textuality.com> Date: Sat, 19 Jul 2003 08:07:57 -0700 From: Tim Bray <tbray@textuality.com> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby <rubys@intertwingly.net> Cc: atom-syntax@imc.org Subject: Re: Extension mechanism References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1941E7.4000901@intertwingly.net> In-Reply-To: <3F1941E7.4000901@intertwingly.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: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> > Danny Ayers wrote: >> >> I believe that such a mechanism can be defined without any impact on the >> work that has been done so far. All I think that is needed in the core >> is a >> means of saying whether an included element from another namespace is >> additional content, *or* is additional information about its parent. It's worth exploring, but could be a rat-hole. The line between metadata and data is super-fuzzy. Also, unless we can figure out how to be really clear what the expected impact on client software is, it's not worth doing. Sam Ruby wrote: > * metadata is actually a matter of perspective. Is the issued date > content or metadata? If LiveJournal wants to capture the mood of the > person while composing this entry, is that additional content or > additional information about the entry? Yep. THere are going to be a million corner cases. > * if we go down this path, it would be worth having something analagous > to the 'mustUnderstand' attribute as defined in the SOAP specification. This seems like a good idea, it's been more or less proven to work in the SOAP context. As I've said before, we shouldn't be trying to invent whizzy new technology here, we should just be trying for a clean clear specification of what's been proven to work. -- Cheers, Tim Bray (ongoing fragmented essay: http://www.tbray.org/ongoing/) From owner-atom-syntax Sat Jul 19 08:09:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JF9qqt099316 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 08:09:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JF9q21099315 for atom-syntax-bks; Sat, 19 Jul 2003 08:09:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JF9kqt099309 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 08:09:46 -0700 (PDT) (envelope-from tbray@textuality.com) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id 522351032A; Sat, 19 Jul 2003 08:09:48 -0700 (PDT) Message-ID: <3F195F3A.5020904@textuality.com> Date: Sat, 19 Jul 2003 08:09:46 -0700 From: Tim Bray <tbray@textuality.com> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: danny666@virgilio.it Cc: atom-syntax@imc.org Subject: Re: Extension mechanism References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> In-Reply-To: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Danny Ayers wrote: > One thing about the syntax that concerns me greatly is that there doesn't > yet appear to be a consistent way of interpreting material from other > namespaces. I believe this to be a make or break issue for interop. This problem has never been solved in the general case that I know of. So I really hope that you're wrong on it's make-or-break-ness. Worth taking a whack at, but don't underestimate the difficulty. -- Cheers, Tim Bray (ongoing fragmented essay: http://www.tbray.org/ongoing/) From owner-atom-syntax Sat Jul 19 08:40:18 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JFeIqt000555 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 08:40:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JFeIme000554 for atom-syntax-bks; Sat, 19 Jul 2003 08:40:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vsmtp3.tin.it (vsmtp3.tin.it [212.216.176.223]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JFeHqt000543 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 08:40:17 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from trotter (80.182.209.190) by vsmtp3.tin.it (7.0.019) id 3F16C22A0009C854; Sat, 19 Jul 2003 17:40:12 +0200 Reply-To: <danny666@virgilio.it> From: "Danny Ayers" <danny666@virgilio.it> To: "Tim Bray" <tbray@textuality.com> Cc: <atom-syntax@imc.org> Subject: RE: Extension mechanism Date: Sat, 19 Jul 2003 17:35:36 +0200 Message-ID: <BKELLDAGKABIOCHDFDBPEEJBDGAA.danny666@virgilio.it> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3F195F3A.5020904@textuality.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> > > One thing about the syntax that concerns me greatly is that > there doesn't > > yet appear to be a consistent way of interpreting material from other > > namespaces. I believe this to be a make or break issue for interop. > > This problem has never been solved in the general case that I know of. > So I really hope that you're wrong on it's make-or-break-ness. Worth > taking a whack at, but don't underestimate the difficulty. (also >As I've said before, we shouldn't be trying to invent whizzy new >technology here, we should just be trying for a clean clear >specification of what's been proven to work.) I believe there is adequate (working!) prior art to point to something that will be appropriate for Atom. I reckon the techniques have been proven, it's just a matter of finding the sweet spot. RDF/XML guarantees we know *something* about material from other namespaces through conformity to the RDF model. It's already been decided that the uber-model approach of using a complete abstract language from which the syntax is derived (as in RDF) isn't desirable, yet RSS 1.0 shows that this approach is possible in the context of syndication. At the other extreme, Sam and others have experimented with directly inserting namespace-qualified xhtml into RSS feeds with the intention that it's there for "display as content". This worked. (Though I can't remember offhand how conflict with other content was handled). Element-wrapping of metadata to hide it is a technique proven in SVG. So I think a braindead simple "this is metadata"/"this is content" data model (expressed in the syntax) for extension material could work. My suggestion for the syntax almost certainly isn't ideal, but it's maybe a start. Cheers, Danny. From owner-atom-syntax Sat Jul 19 08:42:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JFgYqt000848 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 08:42:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JFgYdN000847 for atom-syntax-bks; Sat, 19 Jul 2003 08:42:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from localhost.localdomain (CPE-65-30-234-116.mn.rr.com [65.30.234.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JFgWqt000832 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 08:42:32 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h6JFjdlg023422 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 10:45:39 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h6JFjcYV023418; Sat, 19 Jul 2003 10:45:38 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: <atom-syntax@imc.org> Subject: Re: Extension mechanism References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> From: Ken MacLeod <ken@bitsko.slc.ut.us> Date: 19 Jul 2003 10:45:38 -0500 In-Reply-To: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> Message-ID: <m3adbaa5b1.fsf@bitsko.slc.ut.us> Lines: 36 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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> I think making a distinction, outside of <content>, between what might be "metadata" and what might be "data" is a mistake. Virtually everything we're specifying already *is* metadata about a resource. From Danny's description of a <metadata> element for a feed or an entry, that means we have metadata for our metadata. I think the confusion comes from not knowing whether <entry> is the resource itself vs. <entry> being metadata about another resource (some entity logically or physically in <content>). While it is true that RDF is very clear about this (for any given subject URI, all its properties describe only that subject), RSS 1.0 actually has the same confusion we're talking about here. RSS 1.0 says the subject (rdf:about) of an item "is a URI which identifies the item", but it doesn't make clear whether "the item" is another resource or whether the <rss:item> RDF description itself can be the item. Most common usage is the former, but the latter is often used or proposed for things like tickers, playlists, or other ordered items where the items themselves are the subjects -- many of the same things proposed for Atom. I believe the answer to the question of "is this metadata about a resource or is this entry the resource" is centered around <content>. If content is a complete entity (embedded or by reference), this entry is metadata about the entity resource. If content is not present, empty, or is an entity fragment (the body of a log entry or comment, for example), the entry itself is the resource (content is the body value). In _either_ case, direct children of <entry> describe _the resource_ (as just defined). -- Ken P.S. +1 on a mustUnderstand facility. From owner-atom-syntax Sat Jul 19 09:07:46 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JG7jqt002329 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 09:07:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JG7jpG002328 for atom-syntax-bks; Sat, 19 Jul 2003 09:07:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from localhost.localdomain (CPE-65-30-234-116.mn.rr.com [65.30.234.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JG7iqt002321 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 09:07:44 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h6JGAplg023559 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 11:10:51 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h6JGApHr023555; Sat, 19 Jul 2003 11:10:51 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: <atom-syntax@imc.org> Subject: Re: Extension mechanism References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> From: Ken MacLeod <ken@bitsko.slc.ut.us> Date: 19 Jul 2003 11:10:50 -0500 In-Reply-To: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> Message-ID: <m365lya451.fsf@bitsko.slc.ut.us> Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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> Here are some other facets I see surrounding extension mechanisms, with my preferences stated below: "Wrapping" or "boxing" extensions Extension modules define a wrapper element, properties of the extension appear as children of the extension. Entities and Properties Certain elements are identified as "entities" (as in "entity-relationship model" for RDBs or as classes in OO or RDF). Direct child elements of those entities are either properties or other entities. Entities and properties are fully qualified, either in the core Atom namespace or an extension namespace. Display unknown entities/properties by default Don't display unknown entities/properties by default This relates to how one "ignores what they don't understand." In HTML <body>, unknown elements are treated as if the element tags didn't exist -- their content is displayed by default. My preference is for "Entities and Properties" and "Don't display unknown entities/properties by default." The latter is somewhat in perspective of the former: if these are like columns in a table (where everybody can add their own columns), it doesn't make sense to arbitrarily display every column value. Instead, display well-known columns, columns the user asks for, and columns where another extension column flags that they should be displayed (ie. by providing a stylesheet). -- Ken From owner-atom-syntax Sat Jul 19 09:08:23 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JG8Mqt002339 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 09:08:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JG8M5B002338 for atom-syntax-bks; Sat, 19 Jul 2003 09:08:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ehost004.intermedia.net (ehost004.intermedia.net [206.40.48.177]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JG8Lqt002333 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 09:08:21 -0700 (PDT) (envelope-from joe.madia@workstate.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Extension mechanism Date: Sat, 19 Jul 2003 09:08:22 -0700 Message-ID: <FF1837A1813CF54F8A3579D3F46EB40F038B29EA@ehost004.intermedia.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Extension mechanism Thread-Index: AcNOD+KaeUmsx45OR0mS08hkGCH1Jg== From: "Joe Madia" <joe.madia@workstate.com> To: <atom-syntax@imc.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6JG8Mqt002334 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> A big +1 on attempting to work out some sort of mustUnderstand rule for Atom extensions. On the flip side, I completely agree with Tim's hesitance/pragmatism regarding this issue. My biggest concern: The mustUnderstand header is used successfully in 'some other access protocols' because a rigid processing model is also defined. Atom does not currently (and probably should not) have a predefined processing model and this may limit the ability to add some type of mustUnderstand construct. In spite of the potential problems, I think we should try to work something out... if it becomes a rat hole then we'll just abandon it and move on. Joe From owner-atom-syntax Sat Jul 19 11:07:28 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JI7Sqt007047 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 11:07:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JI7SKq007046 for atom-syntax-bks; Sat, 19 Jul 2003 11:07:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from localhost.localdomain (CPE-65-30-234-116.mn.rr.com [65.30.234.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JI7Rqt007041 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 11:07:27 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h6JIAalg024147 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 13:10:36 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h6JIAZ18024143; Sat, 19 Jul 2003 13:10:35 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: <atom-syntax@imc.org> Subject: Re: Extension mechanism References: <BKELLDAGKABIOCHDFDBPAEJDDGAA.danny666@virgilio.it> From: Ken MacLeod <ken@bitsko.slc.ut.us> Date: 19 Jul 2003 13:10:35 -0500 In-Reply-To: <BKELLDAGKABIOCHDFDBPAEJDDGAA.danny666@virgilio.it> Message-ID: <m3znja8k10.fsf@bitsko.slc.ut.us> Lines: 61 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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> "Danny Ayers" <danny666@virgilio.it> writes: > I was thinking the <metadata> element could go anywhere, so it might > not be about an entry or the feed - the other obvious example being > for it to apply to the <author> of a feed (e.g. some FOAF). > But I'm not sure this is an issue that affects the <metadata> > element if you can put it where you like : > > <link>/weblog/archive/45.html<metadata>...</metadata></link> > > <content> > ...blah... > <metadata>...</metadata> > </content> > > (the link one is a bit ugly-looking, hmm...) <link> and <content> are literal values. Additional markup can only be embedded within them according to their content models. <link> would be #PCDATA and I don't think anyone wants to complicate that by saying element markup can go in there. <content> is based on its media type, but would still logically either be #PCDATA or a content model defined by some other specification (or an Atom content module, as in ComponentBlog). Other elements, like <author>, may themselves be "entity" elements and allow extended properties directly as children. > [...] it doesn't really answer how one might inline content from > another (unknown, arbitrary) namespace - let's say we wanted some > text plus a bit of SVG. If the rule was such content had to go in a > content element of its own, I guess that would work. This was the problem I saw with xhtml:body in RSS that we've solved far more neatly with atom:content. The problem was that xhtml:body is more a "type" than a property name; atom:content is a property name. As far as inlining content from another namespace, the same pattern applies: give it a property name -- the content model is constrained by the schema that defines the property name (readers should expect arbitrary XML for unknown properties). > btw, I personally don't really care too much how this is done, but I > think not sorting it out now would in effect be leaving the broadest > set of use cases (those involving extensions - topics, reviews, > threads, foaf etc etc) without a hook on which to hang their > data. I agree. I described a syntax pattern in Syntax[1] that I believe snapshots a common view of the Atom pattern, but there's not consensus on every part, which I wrote here[2] before the mail list was working right. I think it's very important that we define a general pattern for schema syntaxes so property or extension models are consistent and easier to develop without having to always rethink basic practices. -- Ken [1] http://intertwingly.net/wiki/pie/Syntax [2] http://www.imc.org/atom-syntax/mail-archive/msg00000.html From owner-atom-syntax Sat Jul 19 11:39:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JIdYqt007874 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 11:39:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JIdYjC007873 for atom-syntax-bks; Sat, 19 Jul 2003 11:39:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vsmtp12.tin.it (vsmtp12.tin.it [212.216.176.206]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JIdXqt007840 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 11:39:33 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from trotter (80.182.210.43) by vsmtp12.tin.it (6.7.016) id 3EE0612D00ADCF6F; Sat, 19 Jul 2003 20:39:21 +0200 Reply-To: <danny666@virgilio.it> From: "Danny Ayers" <danny666@virgilio.it> To: "Ken MacLeod" <ken@bitsko.slc.ut.us>, <atom-syntax@imc.org> Subject: RE: Extension mechanism Date: Sat, 19 Jul 2003 20:34:45 +0200 Message-ID: <BKELLDAGKABIOCHDFDBPGEJGDGAA.danny666@virgilio.it> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <m3znja8k10.fsf@bitsko.slc.ut.us> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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> Heh, I must apologise - I only scanned your previous mail, its significance in the context of an extension mechanism flew right past me. > I described a syntax pattern in Syntax[1] that I believe snapshots a > common view of the Atom pattern, but there's not consensus on every > part, which I wrote here[2] before the mail list was working right. > > I think it's very important that we define a general pattern for > schema syntaxes so property or extension models are consistent and > easier to develop without having to always rethink basic practices. Agreed. The "Entity" elements you describe sound mightily like web resources - will these entities each have a URI? Similarly, the property elements correspond well to the parts of RDF with the same name - this could be a big plus for interop. Cheers, Danny. > -- Ken > > [1] http://intertwingly.net/wiki/pie/Syntax > [2] http://www.imc.org/atom-syntax/mail-archive/msg00000.html From owner-atom-syntax Sat Jul 19 13:51:28 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JKpSqt014327 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 13:51:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JKpSwC014325 for atom-syntax-bks; Sat, 19 Jul 2003 13:51:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from gkhs.net (exim@spark.gkhs.net [81.6.252.146]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JKpRqt014320 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 13:51:27 -0700 (PDT) (envelope-from aq+lists@gkhs.net) Received: from maelstrom.water.gkhs.net ([10.1.0.3]) by gkhs.net with smtp (Exim 4.10) id 19dyfw-0001e0-00 for atom-syntax@imc.org; Sat, 19 Jul 2003 21:51:28 +0100 From: Aquarion <aq+lists@gkhs.net> To: atom-syntax@imc.org Subject: Re: Extension mechanism Date: Sat, 19 Jul 2003 21:51:40 +0100 Message-ID: <ebbjhvghjgsspbmodfee0u6ojs3g7h4r9j@4ax.com> References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1941E7.4000901@intertwingly.net> <3F19533D.3050509@willow.frejol.org> In-Reply-To: <3F19533D.3050509@willow.frejol.org> X-Mailer: Forte Agent 1.93/32.576 English (American) 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 h6JKpSqt014321 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> On Sat, 19 Jul 2003 15:18:37 +0100, in gkhs.weblogs.atom-syntax you wrote: > >Sam Ruby wrote: > >> metadata is actually a matter of perspective. Is the issued date >> content or metadata? > >To my mind, the issued date is definitely metadata -- particularly as >our projected format supports various different kinds of date metadata >about a given entry (created, issued, modified, &c, &c). > >> If LiveJournal wants to capture the mood of the person while composing >> this entry, is that additional content or additional information about >> the entry? > >This one's more ambiguous. I'd call it as additional content, I think, >purely on the basis of safe generalisation. Sure, in many cases such >information could arguably be considered metadata, but I reckon I can >project a number of examples where 'mood' isn't a useful piece of >additional information about an entry. So how about if there were two container classes, <content> and <metadata> with same spec, to give the client a hint as to if it should be contained or just referenced to. For example: <atomExample> <content> <item type="text/plain" lang="en">Hello World!</item> <item type="image/gif" src="http://www.aquarionics.com/assets/hello.gif">Hello World image</item> </content> <metadata> <item type="audio/mp3" src="http://www.aquarionics.com/assets/hello.mp3">Aquarion reading "Hello World"</item> <dc:subject>Greetings</dc:subject> <link rel="crossreference" href="http://www2.latech.edu/~acm/HelloWorld.shtml">Hello World in different languages</link> </metadata> </atomExample> This leaves the decision of MetaData up to - primarily - the feed producer and - secondarily - the user agent. -- Aquarion http://www.aquarionics.com From owner-atom-syntax Sat Jul 19 15:06:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JM6bqt019795 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 15:06:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JM6bHN019794 for atom-syntax-bks; Sat, 19 Jul 2003 15:06:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.xaraya.com (xaraya.com [207.44.194.106]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JM6Zqt019787 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 15:06:36 -0700 (PDT) (envelope-from niceguyeddie@xaraya.com) Received: by mail.xaraya.com (Postfix, from userid 1046) id 892F93E00EA; Sat, 19 Jul 2003 22:16:34 +0000 (UTC) Received: from MCNABB (md-wmnsmd-cuda1-c8a-a-99.chvlva.adelphia.net [68.65.108.99]) by mail.xaraya.com (Postfix) with ESMTP id E068B3E00E8 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 22:16:32 +0000 (UTC) Message-ID: <034d01c34e42$2367a930$1202a8c0@MCNABB> From: "J. Cox" <niceguyeddie@xaraya.com> To: <atom-syntax@imc.org> Subject: NNTP Date: Sat, 19 Jul 2003 18:07:25 -0400 Organization: Xaraya X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=0.0 required=5.5 tests=none version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Xaraya's Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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> Hi, Just wondering if there is an NNTP version of this list? If not, I can probably help with some resources, as I am interested in following the development. Thanks! J. Cox http://www.xaraya.com From owner-atom-syntax Sat Jul 19 18:43:29 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6K1hTqt057719 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 18:43:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6K1hSvk057717 for atom-syntax-bks; Sat, 19 Jul 2003 18:43:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vesta.ectoplasm.org (vesta.ectoplasm.org [64.49.222.108]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6K1hRqt057673 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 18:43:27 -0700 (PDT) (envelope-from yining@ectoplasm.org) Received: from [218.5.1.141] (unknown [218.5.1.141]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by vesta.ectoplasm.org (Postfix) with ESMTP id 0EA50A5057 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 20:42:35 -0500 (CDT) Subject: test From: Zhang Yining <yining@ectoplasm.org> To: atom-syntax@imc.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 20 Jul 2003 09:36:32 +0800 Message-Id: <1058665018.6041.24.camel@yining> Mime-Version: 1.0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> how come the emails didn't catch up? From owner-atom-syntax Sat Jul 19 20:36:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6K3abqt076907 for <atom-syntax-bks@above.proper.com>; Sat, 19 Jul 2003 20:36:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6K3ab84076906 for atom-syntax-bks; Sat, 19 Jul 2003 20:36:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6K3aaqt076901 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 20:36:36 -0700 (PDT) (envelope-from joe@bitworking.org) Received: from bitworking.org (adsl-80-203-24.rdu.bellsouth.net [65.80.203.24]) (authenticated) by scandium.sabren.com (8.11.6/8.11.6) with ESMTP id h6K3eDo24570 for <atom-syntax@imc.org>; Sat, 19 Jul 2003 23:40:13 -0400 Message-ID: <3F1A0E41.9090103@bitworking.org> Date: Sat, 19 Jul 2003 23:36:33 -0400 From: Joe Gregorio <joe@bitworking.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Snapshot feedback References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> In-Reply-To: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Here are my comments on the 2003/07/01 snapshot: http://intertwingly.net/stories/2003/07/01/example.necho 1) feed.subtitle should be optional. 2) entry.content - I think there should be only one, and it should be required, and it may be empty. 3) Drop entry.author.weblog and entry.author.weblog, replace with a single element called entry.author.id. Do the same for entry.contributor. Lastly, a clarification, if an element is noted as being required, can it still be zero length? I ask because entry.title is required and has a note that it may be zero length, making me doubt that the other required elements may be zero length. Thanks, -joe -- http://BitWorking.org http://WellFormedWeb.org From owner-atom-syntax Sun Jul 20 05:30:18 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KCUIqt029025 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 05:30:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KCUIXo029023 for atom-syntax-bks; Sun, 20 Jul 2003 05:30:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.fuzzygroup.net ([65.61.162.22]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6KCUGqt029017 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 05:30:16 -0700 (PDT) (envelope-from scott@feedster.com) Received: (qmail 17507 invoked by uid 82); 20 Jul 2003 07:29:31 -0500 Received: from h002078d4bbaa.ne.client2.attbi.com (HELO advalgo.com) (scott@feedster.com@24.60.137.182) by 65.61.162.22 (qmail 1.03 + ejcp) with SMTP; 20 Jul 2003 07:29:31 -0500 Subject: Re: Snapshot feedback From: "J. Scott Johnson" <scott@feedster.com> Reply-To: scott@feedster.com To: atom-syntax@imc.org In-Reply-To: <3F1A0E41.9090103@bitworking.org> References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1A0E41.9090103@bitworking.org> Content-Type: text/plain Organization: Feedster, Inc. Message-Id: <1058704104.7865.133.camel@devserver01.internal> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 20 Jul 2003 08:28:24 -0400 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> Amen! subtitle needs to be optional. IMHO author needs to be optional. If you have any cases of metasyndication like Feedster, you don't have an author at all generally. And if its required then at least allow 0 length. Scott On Sat, 2003-07-19 at 23:36, Joe Gregorio wrote: > Here are my comments on the 2003/07/01 snapshot: > http://intertwingly.net/stories/2003/07/01/example.necho > > 1) feed.subtitle should be optional. > > 2) entry.content - I think there should be only one, > and it should be required, and it may be empty. > > 3) Drop entry.author.weblog and entry.author.weblog, replace > with a single element called entry.author.id. > Do the same for entry.contributor. > > Lastly, a clarification, if an element is noted as being > required, can it still be zero length? I ask because > entry.title is required and has a note that it may be zero > length, making me doubt that the other required elements may > be zero length. > > Thanks, > -joe -- * * * * * * * * * * * * * * * * * * * J. Scott Johnson, Co-Founder Feedster, LLC Making RSS & Weblogs Searchable web: http://www.feedster.com/ mail: scott@feedster.com im: AIM, Y!: fuzzygroup MSN: fuzzygroup@hotmail.com Jabber: fuzzygroup@jabber.com ICQ: 275649261 * * * * * * * * * * * * * * * * * * * From owner-atom-syntax Sun Jul 20 06:01:01 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KD11qt032924 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 06:01:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KD11h2032923 for atom-syntax-bks; Sun, 20 Jul 2003 06:01:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vsmtp12.tin.it (vsmtp12.tin.it [212.216.176.206]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KD0xqt032762 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 06:01:00 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from trotter (80.182.204.98) by vsmtp12.tin.it (6.7.016) id 3EE0612D00AEF0ED; Sun, 20 Jul 2003 15:00:45 +0200 Reply-To: <danny666@virgilio.it> From: "Danny Ayers" <danny666@virgilio.it> To: <scott@feedster.com>, <atom-syntax@imc.org> Subject: RE: Snapshot feedback Date: Sun, 20 Jul 2003 14:56:08 +0200 Message-ID: <BKELLDAGKABIOCHDFDBPGEKJDGAA.danny666@virgilio.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <1058704104.7865.133.camel@devserver01.internal> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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> > subtitle needs to be optional. +1 > IMHO author needs to be optional. If you have any cases of > metasyndication like Feedster, you don't have an author at all > generally. And if its required then at least allow 0 length. If author is considered more generally like dc:creator or even 'agent', then the metasyndication tool itself can be the author. Having said that, I'm not so sure <author> needs to be a mandatory element. There are other machine sources (like the Gump feed [1]) where the URI of the feed performs a similar role, and probably is all you ever need to know. Whether or not this also should be made explicit alongside the feed contents, so it is preserved in republication...I'm really not sure. What is needed is a way of ensuring that attribution to the original source can *somehow* be maintained as well as possible. I think it would also be desirable to make it easy to include/obtain the chain of republishers (machine or human) that an entry had followed from the source to the current presentation, whatever that may be. Cheers, Danny. [1] http://cvs.apache.org/builds/gump/index.rss From owner-atom-syntax Sun Jul 20 06:02:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KD2nqt033205 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 06:02:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KD2nlS033204 for atom-syntax-bks; Sun, 20 Jul 2003 06:02:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.fuzzygroup.net ([65.61.162.22]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6KD2lqt033195 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 06:02:47 -0700 (PDT) (envelope-from scott@feedster.com) Received: (qmail 18515 invoked by uid 82); 20 Jul 2003 08:02:01 -0500 Received: from h002078d4bbaa.ne.client2.attbi.com (HELO advalgo.com) (scott@feedster.com@24.60.137.182) by 65.61.162.22 (qmail 1.03 + ejcp) with SMTP; 20 Jul 2003 08:02:01 -0500 Subject: RE: Snapshot feedback From: "J. Scott Johnson" <scott@feedster.com> Reply-To: scott@feedster.com To: danny666@virgilio.it Cc: atom-syntax@imc.org In-Reply-To: <BKELLDAGKABIOCHDFDBPGEKJDGAA.danny666@virgilio.it> References: <BKELLDAGKABIOCHDFDBPGEKJDGAA.danny666@virgilio.it> Content-Type: text/plain Organization: Feedster, Inc. Message-Id: <1058706054.7865.169.camel@devserver01.internal> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 20 Jul 2003 09:00:55 -0400 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> Re: If author is considered more generally like dc:creator or even 'agent', then the metasyndication tool itself can be the author. If you have the metasyndication tool being the author then the metasyndication tool gets credit for other people's posts. That feels wrong. Scott On Sun, 2003-07-20 at 08:56, Danny Ayers wrote: > > subtitle needs to be optional. > > +1 > > > IMHO author needs to be optional. If you have any cases of > > metasyndication like Feedster, you don't have an author at all > > generally. And if its required then at least allow 0 length. > > If author is considered more generally like dc:creator or even 'agent', then > the metasyndication tool itself can be the author. > > Having said that, I'm not so sure <author> needs to be a mandatory element. > There are other machine sources (like the Gump feed [1]) where the URI of > the feed performs a similar role, and probably is all you ever need to know. > Whether or not this also should be made explicit alongside the feed > contents, so it is preserved in republication...I'm really not sure. > > What is needed is a way of ensuring that attribution to the original source > can *somehow* be maintained as well as possible. I think it would also be > desirable to make it easy to include/obtain the chain of republishers > (machine or human) that an entry had followed from the source to the current > presentation, whatever that may be. > > Cheers, > Danny. > > [1] http://cvs.apache.org/builds/gump/index.rss -- * * * * * * * * * * * * * * * * * * * J. Scott Johnson, Co-Founder Feedster, LLC Making RSS & Weblogs Searchable web: http://www.feedster.com/ mail: scott@feedster.com im: AIM, Y!: fuzzygroup MSN: fuzzygroup@hotmail.com Jabber: fuzzygroup@jabber.com ICQ: 275649261 * * * * * * * * * * * * * * * * * * * From owner-atom-syntax Sun Jul 20 06:07:40 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KD7eqt034076 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 06:07:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KD7ej2034074 for atom-syntax-bks; Sun, 20 Jul 2003 06:07:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vsmtp3.tin.it (vsmtp3.tin.it [212.216.176.223]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KD7dqt034048 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 06:07:39 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from trotter (80.182.204.98) by vsmtp3.tin.it (7.0.019) id 3F16C22A000C379C; Sun, 20 Jul 2003 15:07:31 +0200 Reply-To: <danny666@virgilio.it> From: "Danny Ayers" <danny666@virgilio.it> To: <scott@feedster.com> Cc: <atom-syntax@imc.org> Subject: RE: Snapshot feedback Date: Sun, 20 Jul 2003 15:02:54 +0200 Message-ID: <BKELLDAGKABIOCHDFDBPAEKKDGAA.danny666@virgilio.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <1058706054.7865.169.camel@devserver01.internal> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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> > If author is considered more generally like dc:creator or even 'agent', > then the metasyndication tool itself can be the author. > > If you have the metasyndication tool being the author then the > metasyndication tool gets credit for other people's posts. That feels > wrong. Good point, that's certainly not desirable at the <entry> level. Do we have anything corresponding to creator of the feed yet? From owner-atom-syntax Sun Jul 20 06:33:19 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KDXJqt037420 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 06:33:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KDXIa1037419 for atom-syntax-bks; Sun, 20 Jul 2003 06:33:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [209.61.183.90]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KDXHqt037413 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 06:33:17 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-066.nc.rr.com [66.57.27.66]) (authenticated) by chromium.sabren.com (8.11.6/8.11.6) with ESMTP id h6KDXNA16048 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 09:33:23 -0400 Message-ID: <3F1A9A09.2080601@intertwingly.net> Date: Sun, 20 Jul 2003 09:32:57 -0400 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Snapshot feedback Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Joe Gregorio wrote: > > Here are my comments on the 2003/07/01 snapshot: > http://intertwingly.net/stories/2003/07/01/example.necho > > 1) feed.subtitle should be optional. In rss 2.0, rss.channel.description is required. Looking at typical usages ("theories of software development", "it's just data"), this appears to be best categorized as a subtitle. > 2) entry.content - I think there should be only one, > and it should be required, and it may be empty. I'd like to wait until the API is flushed out before shutting out this possibility. In particular, it would be nice to see what the consensus is for handling multipart (e.g., text + pictures) entries turns out to be. As for "may be empty", consider that there are multiple types of feeds. Some are summary only. Some provide the full content. Some provide both. > 3) Drop entry.author.weblog and entry.author.weblog, replace > with a single element called entry.author.id. > Do the same for entry.contributor. If you had said entry.author.link, I would have agreed. Why "id"? > Lastly, a clarification, if an element is noted as being > required, can it still be zero length? I ask because > entry.title is required and has a note that it may be zero > length, making me doubt that the other required elements may > be zero length. Title being explicitly zero length was intended to promote the idea of a marker entry which indicated essentially "this space intentionally left blank". I expected pushback in the other direction, but perhaps it is better to have marker elements everywhere. > Thanks, > -joe > From owner-atom-syntax Sun Jul 20 06:53:38 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KDrcqt038727 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 06:53:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KDrbID038726 for atom-syntax-bks; Sun, 20 Jul 2003 06:53:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KDraqt038720 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 06:53:37 -0700 (PDT) (envelope-from joe@bitworking.org) Received: from bitworking.org (adsl-80-203-24.rdu.bellsouth.net [65.80.203.24]) (authenticated) by scandium.sabren.com (8.11.6/8.11.6) with ESMTP id h6KDvFL31615 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 09:57:16 -0400 Message-ID: <3F1A9E8C.6060508@bitworking.org> Date: Sun, 20 Jul 2003 09:52:12 -0400 From: Joe Gregorio <joe@bitworking.org> User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Snapshot feedback References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1A0E41.9090103@bitworking.org> <3F1A324C.5020705@apache.org> In-Reply-To: <3F1A324C.5020705@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Sam Ruby wrote: > Joe Gregorio wrote: > >> 3) Drop entry.author.weblog and entry.author.weblog, replace >> with a single element called entry.author.id. >> Do the same for entry.contributor. > > > I would have been with you had you said entry.author.link. Why are > you suggesting an id? entry.author.link is fine, I am not tied to a particular name, I just believe there should be a single URI that identifies the author. One downfall of .weblog and .homepage is that it seems to imply that the author is a person, when in fact the author could be an organization or an automated tool. -joe From owner-atom-syntax Sun Jul 20 07:09:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KE99qt039100 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 07:09:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KE99Tb039091 for atom-syntax-bks; Sun, 20 Jul 2003 07:09:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KE94qt039055 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 07:09:05 -0700 (PDT) (envelope-from joe@bitworking.org) Received: from bitworking.org (adsl-80-203-24.rdu.bellsouth.net [65.80.203.24]) (authenticated) by scandium.sabren.com (8.11.6/8.11.6) with ESMTP id h6KECiL32304 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 10:12:44 -0400 Message-ID: <3F1AA22C.10709@bitworking.org> Date: Sun, 20 Jul 2003 10:07:40 -0400 From: Joe Gregorio <joe@bitworking.org> User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Snapshot feedback (multiple content elements) References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1A0E41.9090103@bitworking.org> <3F1A324C.5020705@apache.org> In-Reply-To: <3F1A324C.5020705@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Sam Ruby wrote: > As far as only one content element per entry goes, I've seen this > brought up a number of times. One thing I would like to see before > this is settled is some more experience with usage as an API. In > particular, I'm interested in multipart blog entries (text plus > pictures). If no compelling need emerges from this, I would agree > that having at most one (or perhaps exactly one) would be simpler. Agreed, more experience with an API would be preferred before changing this. -joe From owner-atom-syntax Sun Jul 20 07:47:40 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KEleqt040397 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 07:47:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KEleDS040396 for atom-syntax-bks; Sun, 20 Jul 2003 07:47:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from localhost.localdomain (CPE-65-30-234-116.mn.rr.com [65.30.234.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KEldqt040391 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 07:47:39 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h6KEp5lg005004 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 09:51:05 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h6KEp5iA005000; Sun, 20 Jul 2003 09:51:05 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: atom-syntax@imc.org Subject: Re: Snapshot feedback References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1A0E41.9090103@bitworking.org> <3F1A324C.5020705@apache.org> <3F1A9E8C.6060508@bitworking.org> From: Ken MacLeod <ken@bitsko.slc.ut.us> Date: 20 Jul 2003 09:51:05 -0500 In-Reply-To: <3F1A9E8C.6060508@bitworking.org> Message-ID: <m3r84l8d5y.fsf@bitsko.slc.ut.us> Lines: 46 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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> Joe Gregorio <joe@bitworking.org> writes: > Sam Ruby wrote: > > > Joe Gregorio wrote: > > > >> 3) Drop entry.author.weblog and entry.author.weblog, replace > >> with a single element called entry.author.id. > >> Do the same for entry.contributor. > > > > I would have been with you had you said entry.author.link. Why > > are you suggesting an id? > > entry.author.link is fine, I am not tied to a particular name, I > just believe there should be a single URI that identifies the > author. For interoperability with RDF, it would be great if any element considered an "entity" have an optional <id> that was the unique URI for that entity. The author case actually ends up being an exception! The RDF folks (and mostly driven by the FOAF folks in particular, who work with this every day) have come to the general conclusion that no one really can come up with a workable URI scheme for "people". Therefore, they recommend foaf:Person *not* have a subject URI and queries be made on otherwise unique properties, such as 'mbox' and, for the spam-blocking challenged, 'mbox_sha1sum' (the latter being just a one-way hash of 'mbox' to prevent email address harvesting). > One downfall of .weblog and .homepage is that it seems to imply that > the author is a person, when in fact the author could be an > organization or an automated tool. Organizations and systems can have weblogs and homepages, too. Occasionally, "weblog" isn't accurate as there is no person specifically selecting the entries to display, but it's still an ordered collection of resources presented day-to-day. Following in the footsteps of the FOAF folks though, none of weblog, homepage, email address, or other property be considered a canonical "id" of that person, organization, or system. You can't just "pick one" and have it make sense as an id in the conceptual model of an author. -- Ken From owner-atom-syntax Sun Jul 20 09:41:20 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KGfKqt045491 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 09:41:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KGfKaN045489 for atom-syntax-bks; Sun, 20 Jul 2003 09:41:20 -0700 (PDT) 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.9/8.12.8) with ESMTP id h6KGfJqt045471 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 09:41:19 -0700 (PDT) (envelope-from jeffreywinter@comcast.net) Received: from winter (h00c04fa0fd63.ne.client2.attbi.com[65.96.172.188](untrusted sender)) by comcast.net (sccrmhc12) with SMTP id <200307201641150120057sl7e>; Sun, 20 Jul 2003 16:41:15 +0000 Message-ID: <002c01c34edd$3fc48ad0$6401a8c0@winter> From: "Jeffrey Winter" <jeffreywinter@comcast.net> To: <atom-syntax@imc.org> References: <BKELLDAGKABIOCHDFDBPEEIKDGAA.danny666@virgilio.it> <3F1A0E41.9090103@bitworking.org> Subject: Re: Snapshot feedback Date: Sun, 20 Jul 2003 12:37:45 -0400 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.3790.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Where do things stand with Comments? Will comments be nested; referenced as shown here: http://www.intertwingly.net/wiki/pie/CommentEntryExample ; or is this still open for debate? Thanks, - Jeff From owner-atom-syntax Sun Jul 20 12:05:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KJ5Yqt059899 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 12:05:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KJ5Y14059898 for atom-syntax-bks; Sun, 20 Jul 2003 12:05:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vsmtp12.tin.it (vsmtp12.tin.it [212.216.176.206]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KJ5Sqt059880 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 12:05:33 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from trotter (80.182.204.42) by vsmtp12.tin.it (6.7.016) id 3EE0612D00AFB1BC; Sun, 20 Jul 2003 21:05:13 +0200 Reply-To: <danny666@virgilio.it> From: "Danny Ayers" <danny666@virgilio.it> To: "Jeffrey Winter" <jeffreywinter@comcast.net>, <atom-syntax@imc.org> Subject: RE: Snapshot feedback Date: Sun, 20 Jul 2003 21:00:37 +0200 Message-ID: <BKELLDAGKABIOCHDFDBPGELCDGAA.danny666@virgilio.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <002c01c34edd$3fc48ad0$6401a8c0@winter> 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> > Where do things stand with Comments? Will comments be nested; > referenced as shown here: > > http://www.intertwingly.net/wiki/pie/CommentEntryExample > > ; or is this still open for debate? I hope it's still open for debate, especially in respect of nested comments if that is expected to go beyond a simple entry-->comments relationship. The structure of comments is just a single aspect of the larger issue of message threading, which IMHO goes way beyond the scope of Atom. Myself and others have looked into this in the context of ThreadsML [1]. If nesting is used for the expression of thread structure, then it is hobbled from the word go - how for example do you represent a comment that summarizes two separate threads? Personally I think it would be better to keep threading (beyond 1:n, entry:comments) away from the core of Atom, though I imagine that it will be one of the early extensions. Cheers, Danny. [1] http://www.quicktopic.com/cgi-bin/thwiki.pl?ThreadsML From owner-atom-syntax Sun Jul 20 12:36:13 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KJaDqt061269 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 12:36:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KJaDxo061268 for atom-syntax-bks; Sun, 20 Jul 2003 12:36:13 -0700 (PDT) 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.9/8.12.8) with ESMTP id h6KJaBqt061263 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 12:36:11 -0700 (PDT) (envelope-from solitude@vkps.co.uk) Received: from modem-1424.baboon.dialup.pol.co.uk ([81.78.21.144] helo=vkps.co.uk) by cmailg2.svr.pol.co.uk with esmtp (Exim 4.14) id 19eJyb-0003HY-DS; Sun, 20 Jul 2003 20:36:09 +0100 Message-ID: <3F1AEF2B.1060906@vkps.co.uk> Date: Sun, 20 Jul 2003 20:36:11 +0100 From: Gary F <solitude@vkps.co.uk> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030616 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby <rubys@intertwingly.net> CC: atom-syntax@imc.org Subject: Re: Snapshot feedback References: <3F1A9A09.2080601@intertwingly.net> In-Reply-To: <3F1A9A09.2080601@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Sam Ruby wrote: > > Joe Gregorio wrote: > >> >> 1) feed.subtitle should be optional. > > > In rss 2.0, rss.channel.description is required. Looking at typical > usages ("theories of software development", "it's just data"), this > appears to be best categorized as a subtitle. > Does anyone read the wiki? We reached consensus on the example page that subtitle should be pulled since we already had summary which does exactly what description does. We agreed to keep one or the other, but not both. Subtitle lost. To catch up, read http://www.intertwingly.net/wiki/pie/SubTitle . It has been linked to from the EchoExample page (where the argument originally occurred) for weeks now. From owner-atom-syntax Sun Jul 20 13:01:25 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KK1Pqt061665 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 13:01:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KK1PNs061664 for atom-syntax-bks; Sun, 20 Jul 2003 13:01:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KK1Oqt061659 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 13:01:24 -0700 (PDT) (envelope-from jjulian2@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h6KK1QqS013512 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 13:01:26 -0700 (PDT) Received: from CompaqLaptop (adsl-66-143-44-20.dsl.ksc2mo.swbell.net [66.143.44.20]) (authenticated bits=0) by mac.com (Xserve/8.12.9/MantshX 2.0) with ESMTP id h6KK1N9d017227 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 13:01:24 -0700 (PDT) Message-Id: <200307202001.h6KK1N9d017227@mac.com> From: "Jeff Julian" <jjulian2@mac.com> To: <atom-syntax@imc.org> Subject: RE: Snapshot feedback Date: Sun, 20 Jul 2003 15:01: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.5329 In-reply-to: <BKELLDAGKABIOCHDFDBPGELCDGAA.danny666@virgilio.it> Thread-Index: AcNO8j0PSFr+OmvFTg+0qbLyTpMItAABr7BQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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> I personally like the idea of nested comments. I think Atom feeds should be easily transformable into the actual blog site itself. My blogging tool, geekswithblogs.com uses the RSS feed with additional nodes, like comments and link categories to build the output site with simple XSLT transforms. http://jjulian.geekswithblogs.com/BlogFeed.aspx is the feed I use to build the site. I would love to see Atom have a similar format. Jeff Julian -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Danny Ayers Sent: Sunday, July 20, 2003 2:01 PM To: Jeffrey Winter; atom-syntax@imc.org Subject: RE: Snapshot feedback > Where do things stand with Comments? Will comments be nested; > referenced as shown here: > > http://www.intertwingly.net/wiki/pie/CommentEntryExample > > ; or is this still open for debate? I hope it's still open for debate, especially in respect of nested comments if that is expected to go beyond a simple entry-->comments relationship. The structure of comments is just a single aspect of the larger issue of message threading, which IMHO goes way beyond the scope of Atom. Myself and others have looked into this in the context of ThreadsML [1]. If nesting is used for the expression of thread structure, then it is hobbled from the word go - how for example do you represent a comment that summarizes two separate threads? Personally I think it would be better to keep threading (beyond 1:n, entry:comments) away from the core of Atom, though I imagine that it will be one of the early extensions. Cheers, Danny. [1] http://www.quicktopic.com/cgi-bin/thwiki.pl?ThreadsML From owner-atom-syntax Sun Jul 20 13:13:29 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KKDTqt062568 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 13:13:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KKDS7K062567 for atom-syntax-bks; Sun, 20 Jul 2003 13:13:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [209.61.183.90]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KKDPqt062558 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 13:13:25 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-066.nc.rr.com [66.57.27.66]) (authenticated) by chromium.sabren.com (8.11.6/8.11.6) with ESMTP id h6KKDVq05001; Sun, 20 Jul 2003 16:13:31 -0400 Message-ID: <3F1AF7CC.9020304@intertwingly.net> Date: Sun, 20 Jul 2003 16:13:00 -0400 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary F <solitude@vkps.co.uk> CC: atom-syntax@imc.org Subject: Re: Snapshot feedback References: <3F1A9A09.2080601@intertwingly.net> <3F1AEF2B.1060906@vkps.co.uk> In-Reply-To: <3F1AEF2B.1060906@vkps.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Gary F wrote: > > Does anyone read the wiki? We reached consensus on the example page that > subtitle should be pulled since we already had summary which does > exactly what description does. We agreed to keep one or the other, but > not both. Subtitle lost. To catch up, read > http://www.intertwingly.net/wiki/pie/SubTitle . > > It has been linked to from the EchoExample page (where the argument > originally occurred) for weeks now. I, for one, would like to see a change log from the 0.1 snapshot. I'm quite willing to produce one, or it could be produced collaboratively. Here's my thoughts on the current example: Feed summary works for me. (I'd prefer subtitle, but ...) Feed modified appears to be gone. At the moment, it appears that author is outside of the entry, which would be problematic for my comment feeds. Contributor is missing. This is supposed to be a 'maximal' feed? A <url> element inside of <author> seems to have replaced <homepage> and <weblog>. <link> would seem to me to be more consistent. Entry id is now an attribute. I'd still prefer a URI. Subtitle is gone from entry. I'm OK with that. Issued is UTC. Sigh. There seems to be a summary inside the entry and inside the first content. Seems redundant. From an xml point of view, mode=escaped and mode=cdata seems redundant. The body in the html example is in the wrong namespace? - Sam Ruby From owner-atom-syntax Sun Jul 20 14:26:44 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KLQiqt069835 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 14:26:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KLQiUc069834 for atom-syntax-bks; Sun, 20 Jul 2003 14:26:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KLQgqt069828 for <atom-syntax@above.proper.com>; Sun, 20 Jul 2003 14:26:43 -0700 (PDT) (envelope-from doug@sonosphere.com) Received: from h-69-3-26-2.snvacaid.covad.net ([69.3.26.2] helo=sonosphere.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19eLhc-0002tA-00 for atom-syntax@above.proper.com; Sun, 20 Jul 2003 14:26:44 -0700 Date: Sun, 20 Jul 2003 14:26:43 -0700 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: snapshot feedback From: Doug Wyatt <doug@sonosphere.com> To: atom-syntax@above.proper.com Content-Transfer-Encoding: 7bit Message-Id: <DBAD9BF4-BAF8-11D7-A7C7-000393A34B5A@sonosphere.com> X-Mailer: Apple Mail (2.552) 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> I hacked together a prototype feed in my custom system: http://www.sonosphere.com/atom.xml I think I was copying from Mark Pilgrim's example as well as the 1.0 snapshot. To elaborate on the unresolved issues I list in a comment at the top of the feed: - <description> makes a lot more sense than <subtitle>. Something for the user to see in an aggregator when trying to decide whether to browse a new feed. - should there be <language> at the feed level? (and more than 1 of them for multilingual feeds?) The RSS 2.0 spec explains that this may be useful for aggregators, to allow the user to search for feeds only in a certain language - having a feed-level <author> seems like a step towards solving both the problem of aggregator-as-author and redundant (and a bit verbose) per-entry <author>s in a single-author feed. - having a feed-level <copyright> seems desirable - (dates, subjects - just notes to myself to do this) The biggest implementation issue, from my POV, is how to treat URL's in HTML embedded in <content>. In my prototype, all the local URL's are absolute paths from the top of my site -- which is not the same as the <feed>/<link>. XIST (the toolkit I'm using) may actually make it relatively painless to transform them into absolute URL's, but it seems simpler all around to have a base URL on the feed -- HTML renderers must have a concept of a base URL, so why not save the generator the trouble of not being able to put one in the feed? Doug From owner-atom-syntax Sun Jul 20 14:36:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KLanqt070188 for <atom-syntax-bks@above.proper.com>; Sun, 20 Jul 2003 14:36:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KLam1b070185 for atom-syntax-bks; Sun, 20 Jul 2003 14:36:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from localhost.localdomain (CPE-65-30-234-116.mn.rr.com [65.30.234.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KLakqt070180 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 14:36:46 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h6KLeJlg007219 for <atom-syntax@imc.org>; Sun, 20 Jul 2003 16:40:19 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h6KLeJt2007215; Sun, 20 Jul 2003 16:40:19 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: <atom-syntax@imc.org> Subject: Re: Snapshot feedback References: <BKELLDAGKABIOCHDFDBPGELCDGAA.danny666@virgilio.it> From: Ken MacLeod <ken@bitsko.slc.ut.us> Date: 20 Jul 2003 16:40:19 -0500 In-Reply-To: <BKELLDAGKABIOCHDFDBPGELCDGAA.danny666@virgilio.it> Message-ID: <m3n0f898sc.fsf@bitsko.slc.ut.us> Lines: 68 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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> "Danny Ayers" <danny666@virgilio.it> writes: > > Where do things stand with Comments? Will comments be nested; > > referenced as shown here: > > > > http://www.intertwingly.net/wiki/pie/CommentEntryExample > The structure of comments is just a single aspect of the larger > issue of message threading, which IMHO goes way beyond the scope of > Atom. Myself and others have looked into this in the context of > ThreadsML [1]. If nesting is used for the expression of thread > structure, then it is hobbled from the word go - how for example do > you represent a comment that summarizes two separate threads? I've been working on a sample RESTful server[2] and am in the process of adding comment support to it, to show POST and GET-queries. One current practice using RSS is to use an RSS channel per weblog item to hold a comment feed. That could use a threading model but I'm not convinced a "feed" is the right way to model comments. An alternative, that I'm sketching out in the sample server, is modeled as a query "what are all the references you have to this URI?", where URI can be the entry, or it can be the weblog, a story, audio, photos, or other resources at the site. References could include other entries, comments, trackbacks, referrers, known directory listings, etc. A similar query returning the same type of results could also be sent to a search site like Technorati or a third-party annotation server, and a reader would then have a union of all the references. The result set would use a highly constrained (minimal data) profile of Atom entities and allow entities from third parties (in their own namespaces): <references xmlns="http://example.com/atom/ns#" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:daypop="http://www.daypop.com/ns#" xmlns:threads="http://purl.org/threads"> <comment> <link>http://bitsko.slc.ut.us/~ken/atom.cgi/comments/restful-1.atom</link> <title>RESTful comment http://bitsko.slc.ut.us/~ken/atom.cgi/entries/restful.atom http://bitsko.slc.ut.us/~ken/atom.cgi/comments/restful-2.atom RESTful comment, part deux http://bitsko.slc.ut.us/~ken/atom.cgi/comments/restful-1.atom http://bitsko.slc.ut.us/~ken/atom.cgi Ken MacLeod's Weblog http://bitsko.slc.ut.us/~ken/atom.cgi/categories/REST RESTful comment, part deux http://www.daypop.com/search?q=link%3Abitsko.slc.ut.us/~ken/atom.cgi/entries/restful.atom Searching All Weblogs for link bitsko.slc.ut.us/~ken/atom.cgi/entries/restful.atom -- Ken > [1] http://www.quicktopic.com/cgi-bin/thwiki.pl?ThreadsML [2] http://bitsko.slc.ut.us/~ken/atom.txt From owner-atom-syntax Sun Jul 20 14:52:50 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KLqoqt070701 for ; Sun, 20 Jul 2003 14:52:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KLqoYq070700 for atom-syntax-bks; Sun, 20 Jul 2003 14:52:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vesta.ectoplasm.org (vesta.ectoplasm.org [64.49.222.108]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KLqnqt070693 for ; Sun, 20 Jul 2003 14:52:49 -0700 (PDT) (envelope-from yining@ectoplasm.org) Received: from [218.5.1.141] (unknown [218.5.1.141]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by vesta.ectoplasm.org (Postfix) with ESMTP id 0F357A5045 for ; Sun, 20 Jul 2003 16:52:43 -0500 (CDT) Subject: Re: Snapshot feedback (multiple content elements) From: Zhang Yining To: Atom-Syntax In-Reply-To: <3F1AA22C.10709@bitworking.org> References: <3F1A0E41.9090103@bitworking.org> <3F1A324C.5020705@apache.org> <3F1AA22C.10709@bitworking.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 21 Jul 2003 05:52:19 +0800 Message-Id: <1058737955.1340.24.camel@yining> Mime-Version: 1.0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 2003-07-20 at 22:07, Joe Gregorio wrote: > > Sam Ruby wrote: > > > As far as only one content element per entry goes, I've seen this > > brought up a number of times. One thing I would like to see before > > this is settled is some more experience with usage as an API. In > > particular, I'm interested in multipart blog entries (text plus > > pictures). If no compelling need emerges from this, I would agree > > that having at most one (or perhaps exactly one) would be simpler. > > Agreed, more experience with an API would be preferred before changing this. > > -joe > Multipart content entry is definitely a requirement, especially for artists who blog about their art works (drawings, photos, musics, etc), and textfying binary data using Base64 should get them into xml. ... YTphYWEFh...YTphWYE ... Here are something important I can think of (there should be more), 1. Ordering - when the feed/entry is retrieved, the order of the content elements is maintained as it was created; 2. Copyright might be applied differently on different content element; 3. Metadata might be necessary for each base64'ed binary content element; I will try to work out an experimental implementation for this. Regards, Yining From owner-atom-syntax Sun Jul 20 15:30:06 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KMU6qt071488 for ; Sun, 20 Jul 2003 15:30:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KMU6jB071487 for atom-syntax-bks; Sun, 20 Jul 2003 15:30:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cmailm2.svr.pol.co.uk (cmailm2.svr.pol.co.uk [195.92.193.210]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KMU5qt071482 for ; Sun, 20 Jul 2003 15:30:05 -0700 (PDT) (envelope-from solitude@vkps.co.uk) Received: from modem-938.dasyure.dialup.pol.co.uk ([81.78.51.170] helo=vkps.co.uk) by cmailm2.svr.pol.co.uk with esmtp (Exim 4.14) id 19eMgj-0006RR-R9; Sun, 20 Jul 2003 23:29:54 +0100 Message-ID: <3F1B17E3.3010504@vkps.co.uk> Date: Sun, 20 Jul 2003 23:29:55 +0100 From: Gary F User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030616 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: atom-syntax@imc.org Subject: Re: Snapshot feedback References: <3F1A9A09.2080601@intertwingly.net> <3F1AEF2B.1060906@vkps.co.uk> <3F1AF7CC.9020304@intertwingly.net> In-Reply-To: <3F1AF7CC.9020304@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: Sam Ruby wrote: > > > Feed summary works for me. (I'd prefer subtitle, but ...) > ... > > Subtitle is gone from entry. I'm OK with that. I think we just wanted to keep this consistent (as I see it, they did the same job at their respective level). > > There seems to be a summary inside the entry and inside the first > content. Seems redundant. > Quite right. I've added a note to the bottom of the EchoExample page about removing it (giving some time to see whether there is a reason for it in the first place). From owner-atom-syntax Sun Jul 20 16:12:25 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KNCPqt072769 for ; Sun, 20 Jul 2003 16:12:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KNCPdh072766 for atom-syntax-bks; Sun, 20 Jul 2003 16:12:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from localhost.localdomain (CPE-65-30-234-116.mn.rr.com [65.30.234.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KNCNqt072759 for ; Sun, 20 Jul 2003 16:12:24 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h6KNFwlg007838 for ; Sun, 20 Jul 2003 18:15:58 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h6KNFwDd007834; Sun, 20 Jul 2003 18:15:58 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: Atom-Syntax Subject: Re: Snapshot feedback (multiple content elements) References: <3F1A0E41.9090103@bitworking.org> <3F1A324C.5020705@apache.org> <3F1AA22C.10709@bitworking.org> <1058737955.1340.24.camel@yining> From: Ken MacLeod Date: 20 Jul 2003 18:15:57 -0500 In-Reply-To: <1058737955.1340.24.camel@yining> Message-ID: Lines: 47 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 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: Zhang Yining writes: > Multipart content entry is definitely a requirement, especially for > artists who blog about their art works (drawings, photos, musics, > etc), and textfying binary data using Base64 should get them into > xml. > > > ... > type=applicatoin/jpg>YTphYWEFh...YTphWYE > ... > Note one of the proposed alternatives, which make only have "one" content but not only supports multiple content, but can distinguish whether those multiple contents are alternatives (pick the best), related (one or more are primary, the rest are used by reference), mixed (don't know which is primary or best), and parallel (try to present all simultaneously, like an image and audio). This alternative is presented on the content[1] and MimeContent[2] pages on the wiki, and looks like this for the example above: ... YTphYWEFh...YTphWYE ... The multipart content type is defined by RFC2046[3]. > 1. Ordering - when the feed/entry is retrieved, the order of the > content elements is maintained as it was created; This is also true within multipart content types. For example, within a multipart/alternative it is defined that the *last* part is the one the publisher thinks is best. -- Ken [1] http://intertwingly.net/wiki/pie/content [2] http://intertwingly.net/wiki/pie/MimeContent [3] http://www.ietf.org/rfc/rfc2046.txt From owner-atom-syntax Sun Jul 20 16:41:57 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KNfvqt074052 for ; Sun, 20 Jul 2003 16:41:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KNfvKF074051 for atom-syntax-bks; Sun, 20 Jul 2003 16:41:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vsmtp3.tin.it (vsmtp3.tin.it [212.216.176.223]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KNfpqt074038 for ; Sun, 20 Jul 2003 16:41:56 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from trotter (80.182.210.19) by vsmtp3.tin.it (7.0.019) id 3F16C22A000DFDF1; Mon, 21 Jul 2003 01:41:42 +0200 Reply-To: From: "Danny Ayers" To: "Ken MacLeod" , Subject: RE: Snapshot feedback Date: Mon, 21 Jul 2003 01:37:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > One current practice using RSS is to use an RSS channel per weblog > item to hold a comment feed. That could use a threading model but I'm > not convinced a "feed" is the right way to model comments. Agreed on the latter point - I think it better to consider the comments as first-class entries, which pretty well follows from prior art in techniques like Dialog Mapping and IBIS. This works well in the RDF model, where, e.g. for IBIS the entries may be instances of Argument, Question or Decision and the relationships between them can be more specific properties than merely a reply, e.g. "pro" if one argument supports another. > An alternative, that I'm sketching out in the sample server, is > modeled as a query "what are all the references you have to this > URI?", where URI can be the entry, or it can be the weblog, a story, > audio, photos, or other resources at the site. References could > include other entries, comments, trackbacks, referrers, known > directory listings, etc. A similar query returning the same type of > results could also be sent to a search site like Technorati or a > third-party annotation server, and a reader would then have a union of > all the references. This is a very interesting approach, and sounds entirely feasible, but I can't help feeling from your example that it's looking tied to specific vocabularies/terms (comment, weblog, category etc) when the query functionality could be completely abstracted away from the (weblog) languages, and made more fine-grained ("what are all the references by Ken since July 2002"). Personally I'd map it all to RDF vocabularies first and use a query language like RQL...but you've probably gathered that that's my hammer of choice. (This isn't far off what's done by the TAP augmented search demo, btw - http://tap.stanford.edu/tap/ss.html) One thing I am sure of is that Atom should be defined in such a way as to make both the approach you describe and my (hypothetical) approach as straightforward to implement as possible. Cheers, Danny. From owner-atom-syntax Tue Jul 22 08:18:55 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MFItqt053510 for ; Tue, 22 Jul 2003 08:18:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MFItKG053509 for atom-syntax-bks; Tue, 22 Jul 2003 08:18:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vsmtp4.tin.it (vsmtp4.tin.it [212.216.176.224]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MFInqt053492 for ; Tue, 22 Jul 2003 08:18:54 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from trotter (80.182.204.146) by vsmtp4.tin.it (7.0.019) id 3F15783200238C4F for atom-syntax@imc.org; Tue, 22 Jul 2003 17:18:39 +0200 Reply-To: From: "Danny Ayers" To: "Atom-Syntax" Subject: FW: Extension mechanism Date: Tue, 22 Jul 2003 17:13:56 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: (This might just be a test - I got a "timed out" response, apologies if it actually made it to the list) > > metadata is actually a matter of perspective. Is the issued date > > content or metadata? > > To my mind, the issued date is definitely metadata -- particularly as > our projected format supports various different kinds of date metadata > about a given entry (created, issued, modified, &c, &c). > > > If LiveJournal wants to capture the mood of the person while composing > > this entry, is that additional content or additional information about > > the entry? > > This one's more ambiguous. I'd call it as additional content, I think, > purely on the basis of safe generalisation. Sure, in many cases such > information could arguably be considered metadata, but I reckon I can > project a number of examples where 'mood' isn't a useful piece of > additional information about an entry. Right. I think these are reasonable examples, both close to the borderline, but I think personally I'd follow your interpretation. This nicely highlights my concern - how is the receiving agent expected to know what to do? By wrapping the issued date in a element the publisher is providing a hint - "don't display this if you don't understand it". On the other hand if 'mood' were expressed directly in an element from another namespace it could be displayed with whatever rendering was considered appropriate for "unknown" content. e.g. [mood : pretty happy] Cheers, Danny. From owner-atom-syntax Sat Jul 26 05:25:56 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6QCPuqt058167 for ; Sat, 26 Jul 2003 05:25:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6QCPueQ058166 for atom-syntax-bks; Sat, 26 Jul 2003 05:25:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.hispeed.ch (mxout.hispeed.ch [62.2.95.247]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6QCPpqt058154 for ; Sat, 26 Jul 2003 05:25:54 -0700 (PDT) (envelope-from michael.wechner@wyona.org) Received: from wyona.org (dclient217-162-174-147.hispeed.ch [217.162.174.147]) by smtp.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with ESMTP id h6QCPjPG015918 for ; Sat, 26 Jul 2003 14:25:46 +0200 Message-ID: <3F22734C.6050409@wyona.org> Date: Sat, 26 Jul 2003 14:25:48 +0200 From: Michael Wechner User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: URI space specification? 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: has anyone started yet with a URI space specification, e.g. Entries: ..../year/month/day/entryid/index.html Feed: ...../feedid/index.html etc. ? Thanks Michael From owner-atom-syntax Sat Jul 26 07:50:52 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6QEoqqt073131 for ; Sat, 26 Jul 2003 07:50:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6QEoqGY073130 for atom-syntax-bks; Sat, 26 Jul 2003 07:50:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6QEooqt073120 for ; Sat, 26 Jul 2003 07:50:50 -0700 (PDT) (envelope-from tbray@textuality.com) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id 1610B10329; Sat, 26 Jul 2003 07:50:47 -0700 (PDT) Message-ID: <3F229546.2090403@textuality.com> Date: Sat, 26 Jul 2003 07:50:46 -0700 From: Tim Bray User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Wechner Cc: atom-syntax@imc.org Subject: Re: URI space specification? References: <3F22734C.6050409@wyona.org> In-Reply-To: <3F22734C.6050409@wyona.org> 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: Michael Wechner wrote: > > has anyone started yet with a URI space specification, e.g. > > Entries: ..../year/month/day/entryid/index.html > > Feed: ...../feedid/index.html Is it a good idea to standardize this? Different publications will have different needs. -- Cheers, Tim Bray (ongoing fragmented essay: http://www.tbray.org/ongoing/) From owner-atom-syntax Sat Jul 26 09:25:26 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6QGPQqt077273 for ; Sat, 26 Jul 2003 09:25:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6QGPQYL077272 for atom-syntax-bks; Sat, 26 Jul 2003 09:25:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vsmtp3.tin.it (vsmtp3.tin.it [212.216.176.223]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6QGPKqt077257 for ; Sat, 26 Jul 2003 09:25:25 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from trotter (80.182.209.185) by vsmtp3.tin.it (7.0.019) id 3F16C22A002F344B; Sat, 26 Jul 2003 18:24:42 +0200 Reply-To: From: "Danny Ayers" To: "Tim Bray" , "Michael Wechner" Cc: Subject: RE: URI space specification? Date: Sat, 26 Jul 2003 18:19:47 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <3F229546.2090403@textuality.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > has anyone started yet with a URI space specification, e.g. > > > > Entries: ..../year/month/day/entryid/index.html > > > > Feed: ...../feedid/index.html > > Is it a good idea to standardize this? Different publications will have > different needs. Any examples? I don't know about standardising as such, but guidelines for blog tools might well help with http://www.intertwingly.net/wiki/pie/BlogMigration Cheers, Danny. From owner-atom-syntax Sat Jul 26 09:27:45 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6QGRjqt077322 for ; Sat, 26 Jul 2003 09:27:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6QGRjlI077321 for atom-syntax-bks; Sat, 26 Jul 2003 09:27:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (law12-oe35.law12.hotmail.com [64.4.18.92]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6QGRiqt077315 for ; Sat, 26 Jul 2003 09:27:44 -0700 (PDT) (envelope-from wkearney99@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 26 Jul 2003 09:27:40 -0700 Received: from 66.92.145.79 by Law12-OE35.adinternal.hotmail.com with DAV; Sat, 26 Jul 2003 16:27:39 +0000 X-Originating-IP: [66.92.145.79] X-Originating-Email: [wkearney99@hotmail.com] Reply-To: "Bill Kearney" From: "Bill Kearney" To: "Tim Bray" , "Michael Wechner" Cc: References: <3F22734C.6050409@wyona.org> <3F229546.2090403@textuality.com> Subject: Re: URI space specification? Date: Sat, 26 Jul 2003 12:27:30 -0400 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 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Message-ID: X-OriginalArrivalTime: 26 Jul 2003 16:27:40.0191 (UTC) FILETIME=[D5174AF0:01C35392] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Is it a good idea to standardize this? Different publications will have > different needs. Different enough to cause endless and rather pointless debates. Now, a mechanism for querying ranges and such, that /would/ be interesting. -Bill Kearney From owner-atom-syntax Sat Jul 26 13:31:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6QKVLqt090694 for ; Sat, 26 Jul 2003 13:31:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6QKVLr5090693 for atom-syntax-bks; Sat, 26 Jul 2003 13:31:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.hispeed.ch (mxout.hispeed.ch [62.2.95.247]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6QKVJqt090684 for ; Sat, 26 Jul 2003 13:31:19 -0700 (PDT) (envelope-from michael.wechner@wyona.org) Received: from wyona.org (dclient217-162-174-147.hispeed.ch [217.162.174.147]) by smtp.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with ESMTP id h6QKVJTU002457; Sat, 26 Jul 2003 22:31:20 +0200 Message-ID: <3F22E51A.2050403@wyona.org> Date: Sat, 26 Jul 2003 22:31:22 +0200 From: Michael Wechner User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: atom-syntax@imc.org Subject: Re: URI space specification? References: <3F22734C.6050409@wyona.org> <3F229546.2090403@textuality.com> In-Reply-To: <3F229546.2090403@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: Tim Bray wrote: > > Michael Wechner wrote: > >> >> has anyone started yet with a URI space specification, e.g. >> >> Entries: ..../year/month/day/entryid/index.html >> >> Feed: ...../feedid/index.html > > > Is it a good idea to standardize this? Different publications will > have different needs. what do you mean by different publications? single-user and multi-user blog? one could certainly define different URI space specs for different publications. Thanks Michael > > From owner-atom-syntax Sat Jul 26 13:28:45 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6QKSjqt090350 for ; Sat, 26 Jul 2003 13:28:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6QKSjvA090349 for atom-syntax-bks; Sat, 26 Jul 2003 13:28:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.hispeed.ch (mxout.hispeed.ch [62.2.95.247]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6QKSgqt090338 for ; Sat, 26 Jul 2003 13:28:43 -0700 (PDT) (envelope-from michael.wechner@wyona.org) Received: from wyona.org (dclient217-162-174-147.hispeed.ch [217.162.174.147]) by smtp.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with ESMTP id h6QKSgER021806 for ; Sat, 26 Jul 2003 22:28:43 +0200 Message-ID: <3F22E47D.50403@wyona.org> Date: Sat, 26 Jul 2003 22:28:45 +0200 From: Michael Wechner User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: atom-syntax@imc.org Subject: Re: URI space specification? 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: Danny Ayers wrote: >>>has anyone started yet with a URI space specification, e.g. >>> >>>Entries: ..../year/month/day/entryid/index.html >>> >>>Feed: ...../feedid/index.html >>> >>> >>Is it a good idea to standardize this? Different publications will have >>different needs. >> >> > >Any examples? > >I don't know about standardising as such, but guidelines for blog tools >might well help with >http://www.intertwingly.net/wiki/pie/BlogMigration > yes, I think the possibility of "blog migration" is a strong enough argument alone to consider a URI specification. Another reason might be to be able to build simple date and topic aware crawlers (resp. queries), which are URL based and don't have to look into each document Since chronology seems to be very important for weblogs, I think it makes sense to build this into the URL and make it "human readable". Although I have to say in the case of newspapers with many editors which are updating the "same" news over time and certain newsitems don't get published immediately this doesn't have to make sense necessarily. But this might be one reason to differentiate between a multiuser blog ("newspaper") and a single-user blog and consider them as different types of publications and hence a different URI space spec. Thanks Michael > >Cheers, >Danny. > > > > From owner-atom-syntax Sat Aug 2 20:12:44 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h733Ciqt051263 for ; Sat, 2 Aug 2003 20:12:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h733Ci4I051262 for atom-syntax-bks; Sat, 2 Aug 2003 20:12:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cabernet.nelson.monkey.org (foobar@adsl-63-194-75-26.dsl.snfc21.pacbell.net [63.194.75.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h733Cgqt051257 for ; Sat, 2 Aug 2003 20:12:42 -0700 (PDT) (envelope-from nelson@monkey.org) Received: by cabernet.nelson.monkey.org (Postfix, from userid 30193) id 4C9CF8C017; Sat, 2 Aug 2003 20:12:44 -0700 (PDT) Message-ID: <16172.32172.285580.160099@cabernet.nelson.monkey.org> Date: Sat, 2 Aug 2003 20:12:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Nelson Minar To: atom-syntax@imc.org Subject: REST API questions Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi there, I'm kibbitzing on the Atom/Echo/nEcho/Pie design. I work at Google and keep a blog, but I'm not really part of the Blogger crew. (I have worked on the Google Web APIs, a SOAP interface). I read Joe's excellent draft of a REST proposal and had a bunch of questions for him. We thought it'd be productive to discuss these questions here on the list. One thing Joe's current draft doesn't talk much about is error signaling. It's easy to design and use an API when there are no errors. It's harder to handle error cases correctly, but it is very important. Some potential errors in a POST API: Wrong password Blog does not exist User over quota Post with that ID already exists Post with that ID does not exist (on delete) ... Errors are mostly just strings, but some of the error data should be structured. For instance, with "ID does not exist" it'd be nice to send back the ID as well. For SOAP, in general SOAP's fault handling is not great but it gets the job done. SOAP uses a element to signal an error, inside a SOAP envelope and body. The fault has some sub elements - faultcode, faultstring, detail, etc. The HTTP binding specifies that faults also throw an HTTP 500 status code. http://www.w3.org/TR/SOAP/#_Toc478383507 I don't think Joe's API proposal covers errors yet. Would errors in a REST API be signaled in HTTP response codes with an XML document in the body of the response to provide detail? Do different HTTP status codes mean different things? I could imagine using 403 Not Authorized for authentication failures. But I think you'd need 500s for most other things; it'd be an abuse of 404 to signal "post with that ID does not exist". And what about non-HTTP transports? What would faults look like in a REST-like API when you're using some other transport? From owner-atom-syntax Sat Aug 2 20:24:40 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h733Odqt051775 for ; Sat, 2 Aug 2003 20:24:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h733Odi4051774 for atom-syntax-bks; Sat, 2 Aug 2003 20:24:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vorpal.notabug.com (qmailr@vorpal.notabug.com [63.149.73.20]) by above.proper.com (8.12.9/8.12.8) with SMTP id h733Ocqt051769 for ; Sat, 2 Aug 2003 20:24:38 -0700 (PDT) (envelope-from me@aaronsw.com) Received: (qmail 8437 invoked from network); 3 Aug 2003 03:24:41 -0000 Received: (ofmipd 12.207.74.63); 3 Aug 2003 03:24:19 -0000 Date: 2 Aug 2003 22:24:40 -0500 Message-Id: <04A06E8C-C562-11D7-9CD3-0003936780B2@aaronsw.com> From: "Aaron Swartz" To: "Nelson Minar" Cc: atom-syntax@imc.org In-Reply-To: <16172.32172.285580.160099@cabernet.nelson.monkey.org> References: <16172.32172.285580.160099@cabernet.nelson.monkey.org> Mime-Version: 1.0 (Apple Message framework v578) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: REST API questions X-Mailer: Apple Mail (2.578) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [I'm copying you because you don't have a Mail-Followup-To header.] Nelson Minar wrote: > Would errors in a REST API be signaled in HTTP response codes with an > XML document in > the body of the response to provide detail? In an XML-based API like ours, probably yes. > But I think you'd need 500s for most other things; it'd be an abuse of > 404 to signal "post with that ID does not exist". I don't know if it'd be an abuse, but it could certainly be confusing. > And what about non-HTTP transports? What would faults look like in a > REST-like API when you're using some other transport? What sorts of non-HTTP transports are you thinking of? I think part of the idea of REST is to use HTTP and reinvent the wheel. -- Aaron Swartz: http://www.aaronsw.com/ From owner-atom-syntax Sat Aug 2 20:27:13 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h733RDqt051820 for ; Sat, 2 Aug 2003 20:27:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h733RD64051819 for atom-syntax-bks; Sat, 2 Aug 2003 20:27:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cabernet.nelson.monkey.org (foobar@adsl-63-194-75-26.dsl.snfc21.pacbell.net [63.194.75.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h733RBqt051814 for ; Sat, 2 Aug 2003 20:27:12 -0700 (PDT) (envelope-from nelson@monkey.org) Received: by cabernet.nelson.monkey.org (Postfix, from userid 30193) id C33058C017; Sat, 2 Aug 2003 20:27:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16172.33042.769935.127965@cabernet.nelson.monkey.org> Date: Sat, 2 Aug 2003 20:27:14 -0700 From: Nelson Minar To: "Aaron Swartz" Cc: atom-syntax@imc.org Subject: Re: REST API questions In-Reply-To: <04A06E8C-C562-11D7-9CD3-0003936780B2@aaronsw.com> References: <16172.32172.285580.160099@cabernet.nelson.monkey.org> <04A06E8C-C562-11D7-9CD3-0003936780B2@aaronsw.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> And what about non-HTTP transports? >What sorts of non-HTTP transports are you thinking of? I think part of >the idea of REST is to use HTTP and reinvent the wheel. HTTP will certainly be a primary transport, but I think a message queue / store and forward transport such as SMTP could also be useful. From owner-atom-syntax Sat Aug 2 20:32:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h733W3qt051913 for ; Sat, 2 Aug 2003 20:32:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h733W3co051912 for atom-syntax-bks; Sat, 2 Aug 2003 20:32:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h733W2qt051907 for ; Sat, 2 Aug 2003 20:32:02 -0700 (PDT) (envelope-from joe@bitworking.org) Received: from bitworking.org (adsl-80-204-233.rdu.bellsouth.net [65.80.204.233]) (authenticated) by scandium.sabren.com (8.11.6/8.11.6) with ESMTP id h733Xvx18505; Sat, 2 Aug 2003 23:33:57 -0400 Message-ID: <3F2C822E.8020807@bitworking.org> Date: Sat, 02 Aug 2003 23:31:58 -0400 From: Joe Gregorio User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nelson Minar CC: atom-syntax@imc.org Subject: Re: REST API questions References: <16172.32172.285580.160099@cabernet.nelson.monkey.org> In-Reply-To: <16172.32172.285580.160099@cabernet.nelson.monkey.org> 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: Nelson Minar wrote: > Hi there, I'm kibbitzing on the Atom/Echo/nEcho/Pie design. I work at > Google and keep a blog, but I'm not really part of the Blogger crew. > (I have worked on the Google Web APIs, a SOAP interface). > > I read Joe's excellent draft of a REST proposal and had a bunch of > questions for him. We thought it'd be productive to discuss these > questions here on the list. > > > One thing Joe's current draft doesn't talk much about is error > signaling. It's easy to design and use an API when there are no > errors. It's harder to handle error cases correctly, but it is very > important. > > Some potential errors in a POST API: > Wrong password > Blog does not exist > User over quota > Post with that ID already exists > Post with that ID does not exist (on delete) > ... In a REST form of the API you would see something different, on a case by case basis you get: > Wrong password Return HTTP status code 401/403 > Blog does not exist Return 404 since that URI identifies the blog, or more appropriately 410 if they got Jon Robb'd. > User over quota Could be either 413 or 500 > Post with that ID already exists This can not happen in the REST form of the API. > Post with that ID does not exist (on delete) This is not an error in the REST form of the API. Each entry has it's own URI and DELETEing a resource returns a 200 on success whether the resource existed at the time or not. > > Errors are mostly just strings, but some of the error data should be > structured. For instance, with "ID does not exist" it'd be nice to > send back the ID as well. > Kind of a red-herring since in the REST form of the API these problems don't exist. Even if there could be an error, the client that made the request knows which entry it was trying to delete, given that the client probably got the URI from the search interface, it already has the title of the entry to display to the user. > For SOAP, in general SOAP's fault handling is not great but it gets > the job done. SOAP uses a element to signal an error, > inside a SOAP envelope and body. The fault has some sub elements - > faultcode, faultstring, detail, etc. The HTTP binding specifies that > faults also throw an HTTP 500 status code. > http://www.w3.org/TR/SOAP/#_Toc478383507 > > I don't think Joe's API proposal covers errors yet. Would errors in a > REST API be signaled in HTTP response codes with an XML document in > the body of the response to provide detail? Do different HTTP status > codes mean different things? I could imagine using 403 Not Authorized > for authentication failures. But I think you'd need 500s for most > other things; it'd be an abuse of 404 to signal "post with that ID > does not exist". Yes, 404 would be an abuse if you used POST to update entries, but if you used PUT and the entry was uniquely identified by its URI then it would be perfectly appropriate to use 404 or 410. > > And what about non-HTTP transports? What would faults look like in a > REST-like API when you're using some other transport? > You are right that the specification at this time does not cover error codes. In general the HTTP Status code should be the first line of defense, such as 403 Not Authorized, etc. There are errors that will need more detail than just the status code, and I see three possibilities: 1. Do nothing. That is, let the server decide the error code and formatting to return it in. For example, when you get a 404 on a web-site you often get an HTML page or a text/plain document. Not my favorite option. 2. Mandate a text/plain result that describes the problem. 3. The third option is to define an XML format for describing errors, e.g. Thanks, -joe -- http://BitWorking.org http://WellFormedWeb.org From owner-atom-syntax Sun Aug 3 08:46:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h73FkYqt013728 for ; Sun, 3 Aug 2003 08:46:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h73FkYSW013727 for atom-syntax-bks; Sun, 3 Aug 2003 08:46:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cabernet.nelson.monkey.org (foobar@adsl-63-194-75-26.dsl.snfc21.pacbell.net [63.194.75.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h73FkWqt013722 for ; Sun, 3 Aug 2003 08:46:32 -0700 (PDT) (envelope-from nelson@monkey.org) Received: by cabernet.nelson.monkey.org (Postfix, from userid 30193) id 2F8EF8C017; Sun, 3 Aug 2003 08:46:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16173.11865.125417.204440@cabernet.nelson.monkey.org> Date: Sun, 3 Aug 2003 08:46:33 -0700 From: Nelson Minar To: Joe Gregorio Cc: atom-syntax@imc.org Subject: Re: REST API questions In-Reply-To: <3F2C822E.8020807@bitworking.org> References: <16172.32172.285580.160099@cabernet.nelson.monkey.org> <3F2C822E.8020807@bitworking.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This discussion is really helpful for me in clarifying the REST proposal. I hope it's useful for others, too! Joe, one more broad question that came up in reading your reply: how do I uniquely refer to entries in your REST API proposal? I gather it's from the URI for the entry: HTTP/1.1 201 Created Location: http://example.org/reilly/1 Several blog engines (Blogger, I think Movable Type?) don't really have a single-URI-per-entry model. Or they do, but the URI includes an anchor to be unique: http://www.blogger.com/developers/2003_07_01_archive.pyra#105711794730830300 I've always thought this was a bad way to do permalinks, but it's common practice. Does this pose a problem for using URIs to identify entries? HTTP clients don't send the stuff after the #; they use it locally to find the point inside the file. So if my HTTP client sends http://www.blogger.com/developers/2003_07_01_archive.pyra when trying to do an update/delete, how will the API know which post I meant? On to your reply: >> Blog does not exist >Return 404 since that URI identifies the blog, or more appropriately 410 >if they got Jon Robb'd. How do you distinguish the "404 there's no API server at that URI" from "404 you found the API server but there's an application level error about the location of the blog"? I know it's central to get this stuff right in REST, but I don't know how. To take your example: http://dev.example.net/api?userid=reilly&action=create If a client gets a 404 does it mean there's no API at http://dev.example.net/api? Or does it mean there's no user "reilly"? > > Post with that ID already exists >This can not happen in the REST form of the API. Is this because your proposal doesn't put the entry ID in the upload? I fear this will be a bit tricky in Blosxom; blog entries are filenames are URLs, so when I create a new entry I'm going to want to specify the URI. Ie, I want to create http://www.nelson.monkey.org/~nelson/weblog/culture/games/Tron20.html The fact that it's named "Tron20" is important to me - how do I tell the create API what this name is? > > Post with that ID does not exist (on delete) >This is not an error in the REST form of the API. Each entry has it's >own URI and DELETEing a resource returns a 200 on success whether the >resource existed at the time or not. I think this is a mistake - it's important when a user tries to delete something to tell them whether the delete succeeded or not. One kind of failure is "the thing you tried to delete doesn't exist". APIs are hard! Nelson From owner-atom-syntax Sun Aug 3 09:25:43 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h73GPhqt014501 for ; Sun, 3 Aug 2003 09:25:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h73GPho4014500 for atom-syntax-bks; Sun, 3 Aug 2003 09:25:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h73GPgqt014495 for ; Sun, 3 Aug 2003 09:25:42 -0700 (PDT) (envelope-from joe@bitworking.org) Received: from bitworking.org (adsl-80-204-233.rdu.bellsouth.net [65.80.204.233]) (authenticated) by scandium.sabren.com (8.11.6/8.11.6) with ESMTP id h73GRfn08314; Sun, 3 Aug 2003 12:27:41 -0400 Message-ID: <3F2D3727.1080704@bitworking.org> Date: Sun, 03 Aug 2003 12:24:07 -0400 From: Joe Gregorio User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nelson Minar CC: atom-syntax@imc.org Subject: Re: REST API questions References: <16172.32172.285580.160099@cabernet.nelson.monkey.org> <3F2C822E.8020807@bitworking.org> <16173.11865.125417.204440@cabernet.nelson.monkey.org> In-Reply-To: <16173.11865.125417.204440@cabernet.nelson.monkey.org> Content-Type: multipart/alternative; boundary="------------070007000709000407020200" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --------------070007000709000407020200 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nelson Minar wrote: >This discussion is really helpful for me in clarifying the REST >proposal. I hope it's useful for others, too! > > I hope so, because it's been very useful for me. > >Joe, one more broad question that came up in reading your reply: how >do I uniquely refer to entries in your REST API proposal? I gather >it's from the URI for the entry: > HTTP/1.1 201 Created > Location: http://example.org/reilly/1 > >Several blog engines (Blogger, I think Movable Type?) don't really >have a single-URI-per-entry model. Or they do, but the URI includes an >anchor to be unique: > http://www.blogger.com/developers/2003_07_01_archive.pyra#105711794730830300 >I've always thought this was a bad way to do permalinks, but it's >common practice. > >Does this pose a problem for using URIs to identify entries? HTTP >clients don't send the stuff after the #; they use it locally to find >the point inside the file. So if my HTTP client sends > http://www.blogger.com/developers/2003_07_01_archive.pyra >when trying to do an update/delete, how will the API know which post I meant? > > I think an important point to stress here is that there doesn't need to be any relationship between the API URIs and the final weblog content URIs. While your posts may sit at http://www.blogger.com/developers/2003_07_01_archive.pyra The unique URIs for each entry may have the form of : http://dev.example.net/api?userid=reilly&postid=12 Each post needs to be uniquely identified, just like it is in the Blogger 2.0 API: http://www.blogger.com/developers/api/documentation20.html#post >On to your reply: > >>> Blog does not exist >>> >>> >>Return 404 since that URI identifies the blog, or more appropriately 410 >>if they got Jon Robb'd. >> >> > >How do you distinguish the "404 there's no API server at that URI" >from "404 you found the API server but there's an application level >error about the location of the blog"? I know it's central to get this >stuff right in REST, but I don't know how. > An application level error would be a 5XX series. More specifically, there already exists a defined set of error codes for problems with URIs and actions on them. They are outlined in RFC2616, and they can be used directly here. Now we may come across situations where those codes are inadequate, and in that case we can add another code. WebDAV, for example, added several new status codes. >>> Post with that ID already exists >>> >>> >>This can not happen in the REST form of the API. >> >> > >Is this because your proposal doesn't put the entry ID in the upload? > > Yes. >I fear this will be a bit tricky in Blosxom; blog entries are >filenames are URLs, so when I create a new entry I'm going to want to >specify the URI. Ie, I want to create > http://www.nelson.monkey.org/~nelson/weblog/culture/games/Tron20.html >The fact that it's named "Tron20" is important to me - how do I tell >the create API what this name is? > This is an excellent question, and looks like a current weakness in the AtomAPI as specified. How do other weblogging systems allocate their URIs? Just to get some more details, it looks like the portion of the path /culture/games is the category? And Tron20 is the Entry title? >>> Post with that ID does not exist (on delete) >>> >>> >>This is not an error in the REST form of the API. Each entry has it's >>own URI and DELETEing a resource returns a 200 on success whether the >>resource existed at the time or not. >> >> > >I think this is a mistake - it's important when a user tries to delete >something to tell them whether the delete succeeded or not. > But it did succeed, the resource is not there. Using a 200 doesn't bar you from returning a response body with more details, like one of the three options I outlined in my last message. >APIs are hard! > Nelson > > Agreed, and all your questions are very helpful. Keep them coming! Thanks, -joe --------------070007000709000407020200 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Nelson Minar wrote:

This discussion is really helpful for me in clarifying the REST
proposal. I hope it's useful for others, too!

I hope so, because it's been very useful for me.


Joe, one more broad question that came up in reading your reply: how
do I uniquely refer to entries in your REST API proposal? I gather
it's from the URI for the entry:
  HTTP/1.1 201 Created
  Location: http://example.org/reilly/1

Several blog engines (Blogger, I think Movable Type?) don't really
have a single-URI-per-entry model. Or they do, but the URI includes an
anchor to be unique:
  http://www.blogger.com/developers/2003_07_01_archive.pyra#105711794730830300
I've always thought this was a bad way to do permalinks, but it's
common practice.

Does this pose a problem for using URIs to identify entries? HTTP
clients don't send the stuff after the #; they use it locally to find
the point inside the file. So if my HTTP client sends
  http://www.blogger.com/developers/2003_07_01_archive.pyra
when trying to do an update/delete, how will the API know which post I meant?

I think an important point to stress here is that there doesn't need to be any relationship between
the API URIs and the final weblog content URIs. While your posts may sit at
http://www.blogger.com/developers/2003_07_01_archive.pyra
The unique URIs for each entry may have the form of :
http://dev.example.net/api?userid=reilly&postid=12
Each post needs to be uniquely identified, just like it is in the Blogger 2.0 API:
http://www.blogger.com/developers/api/documentation20.html#post

On to your reply:

  Blog does not exist

Return 404 since that URI identifies the blog, or more appropriately 410 
if they got Jon Robb'd.


How do you distinguish the "404 there's no API server at that URI"
from "404 you found the API server but there's an application level
error about the location of the blog"? I know it's central to get this
stuff right in REST, but I don't know how.

An application level error would be a 5XX series. More specifically, there already exists
a defined set of error codes for problems with URIs and actions on them. They are
outlined in RFC2616, and they can be used directly here. Now we may come across
situations where those codes are inadequate, and in that case we can add another code.
WebDAV, for example, added several new status codes.

  Post with that ID already exists

This can not happen in the REST form of the API.


Is this because your proposal doesn't put the entry ID in the upload?

Yes.

I fear this will be a bit tricky in Blosxom; blog entries are
filenames are URLs, so when I create a new entry I'm going to want to
specify the URI. Ie, I want to create
  http://www.nelson.monkey.org/~nelson/weblog/culture/games/Tron20.html
The fact that it's named "Tron20" is important to me - how do I tell
the create API what this name is?

This is an excellent question, and looks like a current weakness in the AtomAPI as specified.
How do other weblogging systems allocate their URIs?
Just to get some more details, it looks like the portion of the path /culture/games is the category?
And Tron20 is the Entry title?

  Post with that ID does not exist (on delete)

This is not an error in the REST form of the API. Each entry has it's 
own URI and DELETEing a resource returns a 200 on success whether the 
resource existed at the time or not.


I think this is a mistake - it's important when a user tries to delete
something to tell them whether the delete succeeded or not.

But it did succeed, the resource is not there. Using a 200 doesn't bar you from returning a response
body with more details, like one of the three options I outlined in my last message.

APIs are hard!
  Nelson

Agreed, and all your questions are very helpful. Keep them coming!

Thanks,
-joe

--------------070007000709000407020200-- From owner-atom-syntax Sun Aug 3 09:49:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h73GnLqt014979 for ; Sun, 3 Aug 2003 09:49:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h73GnLWI014978 for atom-syntax-bks; Sun, 3 Aug 2003 09:49:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cabernet.nelson.monkey.org (foobar@adsl-63-194-75-26.dsl.snfc21.pacbell.net [63.194.75.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h73GnJqt014973 for ; Sun, 3 Aug 2003 09:49:19 -0700 (PDT) (envelope-from nelson@monkey.org) Received: by cabernet.nelson.monkey.org (Postfix, from userid 30193) id F1EB68C017; Sun, 3 Aug 2003 09:49:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16173.15632.958930.845853@cabernet.nelson.monkey.org> Date: Sun, 3 Aug 2003 09:49:20 -0700 From: Nelson Minar To: Joe Gregorio Cc: atom-syntax@imc.org Subject: Re: REST API questions In-Reply-To: <3F2D3727.1080704@bitworking.org> References: <16172.32172.285580.160099@cabernet.nelson.monkey.org> <3F2C822E.8020807@bitworking.org> <16173.11865.125417.204440@cabernet.nelson.monkey.org> <3F2D3727.1080704@bitworking.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is great. We really need a similarly fleshed out SOAP proposal so folks can try to poke holes in it too. Alas, I don't have the time to produce one. The Blogger folks have a start on one, has anyone gone further with it? One more question on HTTP codes - do you mean HTTP/1.0 response codes or HTTP/1.1? Or do servers need to provide either? HTTP is not HTTP. >>How do you distinguish the "404 there's no API server at that URI" >>from "404 you found the API server but there's an application level >>error about the location of the blog"? >An application level error would be a 5XX series. Now I'm confused. Before, yu suggested using 404 in the case where I try to upload a new entry to a blog that does not exist. But that's an application level error, not an HTTP transport level error. So are you saying now I should use a 5XX? Again, the specific example is if I try to create a new entry for a blog that doesn't exist. >More specifically, there already exists a defined set of error codes >for problems with URIs and actions on them. They are outlined in >RFC2616, and they can be used directly here. Using HTTP response codes is part of the magic of REST. But the codes are designed for transporting Web documents. I fear in some cases they may be ambiguous when applied to an application layered on top of HTTP such as an Atom API. This possibility is at the heart of the argument for/against REST, so it's useful to get detailed about it. >Now we may come across situations where those codes are inadequate, >and in that case we can add another code. Yikes, I really hope we don't have to do that. A big appeal of the REST binding of Atom is that it reuses HTTP. If we start having to extend HTTP we're in trouble. >>>DELETEing a resource returns a 200 on success whether the >>>resource existed at the time or not. >>I think this is a mistake - it's important when a user tries to delete >>something to tell them whether the delete succeeded or not. >But it did succeed, the resource is not there. What if I blogged something terrible, like "myCatIsATerrorist.txt". I reconsider, so I go into my handy client software and tell it to delete "myCatIsATerorist.txt" [sic]. The client posts the delete with the incorrect URI, but the server merrily returns a "200 OK". I now think I've deleted the blog entry, but it's still there. Returning an error on delete is really helpful. Every filesystem-like API I've ever used returns an error code on delete, I don't see why this sould be different. The questions about non-HTTP REST bindings got lost. We have enough to talk about here already, so I'll leave it for someone else to take up. It is a fundamental question - should the Atom API be HTTP only, or should it be protocol independent? From owner-atom-syntax Sun Aug 3 09:57:46 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h73Gvkqt015169 for ; Sun, 3 Aug 2003 09:57:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h73Gvkj0015168 for atom-syntax-bks; Sun, 3 Aug 2003 09:57:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cabernet.nelson.monkey.org (foobar@adsl-63-194-75-26.dsl.snfc21.pacbell.net [63.194.75.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h73Gviqt015163 for ; Sun, 3 Aug 2003 09:57:44 -0700 (PDT) (envelope-from nelson@monkey.org) Received: by cabernet.nelson.monkey.org (Postfix, from userid 30193) id EA2EB8C017; Sun, 3 Aug 2003 09:57:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16173.16137.935598.450286@cabernet.nelson.monkey.org> Date: Sun, 3 Aug 2003 09:57:45 -0700 From: Nelson Minar To: Joe Gregorio Cc: atom-syntax@imc.org Subject: creating entries - categories, filenames In-Reply-To: <3F2D3727.1080704@bitworking.org> References: <16172.32172.285580.160099@cabernet.nelson.monkey.org> <3F2C822E.8020807@bitworking.org> <16173.11865.125417.204440@cabernet.nelson.monkey.org> <3F2D3727.1080704@bitworking.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This isn't really about REST, so I'm replying separately: >>when I create a new entry I'm going to want to specify the URI. Ie, >>I want to create >> http://www.nelson.monkey.org/~nelson/weblog/culture/games/Tron20.html >Just to get some more details, it looks like the portion of the path >/culture/games is the category? And Tron20 is the Entry title? Close. /culture/games is the category, and in Blosxom categories are hierarchical. "Tron20" is the name of the file on disk (actually it's "Tron20.txt"). The only place "Tron20" is displayed is in the URI. (*) >How do other weblogging systems allocate their URIs? I think it's all over the map. Blogger seems to create date & timestamp URIs. Blosxom's simplicity is that each entry is a file on disk, and the URI is just the pathname. This may be a candidate for extensions. Blogger doesn't do categories or filenames, so needs neither. Blosxom could pick up the filename from a special Blosxom extension tag, and could use a category tag for the dirname. I'm surprised not to see category as an optional element in Sam's 0.1 snapshot, but I see on the Wiki there's a lot of discussion about the idea. (*) For completeness on Blosxom URLs, Blosxom does one weirder with flavours. These are both valid views of the same entry: http://www.nelson.monkey.org/~nelson/weblog/culture/games/Tron20.html http://www.nelson.monkey.org/~nelson/weblog/culture/games/Tron20.rss091 Stuff after the "." is a flavour. Users can add new flavours. I think the posting API can ignore this stuff, though, and treat the /Tron20 as the canonical name. From owner-atom-syntax Sun Aug 3 20:06:48 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7436mqt042173 for ; Sun, 3 Aug 2003 20:06:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7436mjZ042172 for atom-syntax-bks; Sun, 3 Aug 2003 20:06:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7436kqt042167 for ; Sun, 3 Aug 2003 20:06:46 -0700 (PDT) (envelope-from tbray@textuality.com) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id 47DB610344; Sun, 3 Aug 2003 20:06:44 -0700 (PDT) Message-ID: <3F2DCDC6.8010405@textuality.com> Date: Sun, 03 Aug 2003 20:06:46 -0700 From: Tim Bray User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nelson Minar Cc: Joe Gregorio , atom-syntax@imc.org Subject: Re: creating entries - categories, filenames References: <16172.32172.285580.160099@cabernet.nelson.monkey.org> <3F2C822E.8020807@bitworking.org> <16173.11865.125417.204440@cabernet.nelson.monkey.org> <3F2D3727.1080704@bitworking.org> <16173.16137.935598.450286@cabernet.nelson.monkey.org> In-Reply-To: <16173.16137.935598.450286@cabernet.nelson.monkey.org> 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: Nelson Minar wrote: >>>when I create a new entry I'm going to want to specify the URI. Ie, >>>I want to create >>> http://www.nelson.monkey.org/~nelson/weblog/culture/games/Tron20.html > >>Just to get some more details, it looks like the portion of the path >>/culture/games is the category? And Tron20 is the Entry title? I don't think it matters. There are going to be some publishing systems that let authors pick URIs and in fact my home-grown one at ongoing *requires* me to pick, so in the API, the create-entry operation has to include an (optional) URI, the required/forbidden/advisory semantics of which are going to vary from system to system. Clearly pretty well every publishing system is going to have some sort of built-in naming hierarchy (I'm pretty convinced that date-based ones win). I'm not sure if it's worth the effort to try to standardize this, at least for the base-level API. >>How do other weblogging systems allocate their URIs? > > I think it's all over the map. Yep. One more opinion; it's bogus to encode the category in the URI; I've never understood why an entry needs more than one URI, that doesn't keep you from having a category page that points to non-category-based URIs. But I digress. -- Cheers, Tim Bray (ongoing fragmented essay: http://www.tbray.org/ongoing/) From owner-atom-syntax Sun Aug 3 20:24:56 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h743Otqt044472 for ; Sun, 3 Aug 2003 20:24:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h743OtFe044470 for atom-syntax-bks; Sun, 3 Aug 2003 20:24:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h743Osqt044463 for ; Sun, 3 Aug 2003 20:24:54 -0700 (PDT) (envelope-from joe@bitworking.org) Received: from bitworking.org (adsl-80-204-233.rdu.bellsouth.net [65.80.204.233]) (authenticated) by scandium.sabren.com (8.11.6/8.11.6) with ESMTP id h743Qwj11278; Sun, 3 Aug 2003 23:26:58 -0400 Message-ID: <3F2DD200.5050405@bitworking.org> Date: Sun, 03 Aug 2003 23:24:48 -0400 From: Joe Gregorio User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nelson Minar CC: atom-syntax@imc.org Subject: Re: REST API questions References: <16172.32172.285580.160099@cabernet.nelson.monkey.org> <3F2C822E.8020807@bitworking.org> <16173.11865.125417.204440@cabernet.nelson.monkey.org> <3F2D3727.1080704@bitworking.org> <16173.15632.958930.845853@cabernet.nelson.monkey.org> In-Reply-To: <16173.15632.958930.845853@cabernet.nelson.monkey.org> 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: Nelson Minar wrote: > This is great. We really need a similarly fleshed out SOAP proposal so > folks can try to poke holes in it too. Alas, I don't have the time to > produce one. The Blogger folks have a start on one, has anyone gone > further with it? > > > One more question on HTTP codes - do you mean HTTP/1.0 response codes > or HTTP/1.1? Or do servers need to provide either? HTTP is not HTTP. Hmm, I had assumed HTTP/1.1, any information you can provide on the distribution of 1.1 versus 1.0 and things to be concerned about? >>>How do you distinguish the "404 there's no API server at that URI" >>>from "404 you found the API server but there's an application level >>>error about the location of the blog"? >>An application level error would be a 5XX series. > > Now I'm confused. Before, yu suggested using 404 in the case where I > try to upload a new entry to a blog that does not exist. But that's an > application level error, not an HTTP transport level error. So are you > saying now I should use a 5XX? Again, the specific example is if I try > to create a new entry for a blog that doesn't exist. Ok, I misunderstood what you meant by "application error", to be the program crashed or some other type of internal error when it got that request. In that case a 5XX would be appropriate, yes? I think in this case, and each of the examples you outline below, there is no problem with using the closest HTTP status code that matches the situation and adding in a response body with message details. >>More specifically, there already exists a defined set of error codes >>for problems with URIs and actions on them. They are outlined in >>RFC2616, and they can be used directly here. > > Using HTTP response codes is part of the magic of REST. But the codes > are designed for transporting Web documents. I fear in some cases they > may be ambiguous when applied to an application layered on top of HTTP > such as an Atom API. This possibility is at the heart of the argument > for/against REST, so it's useful to get detailed about it. Wow, I have never heard a rationalization for REST that relied heavily on the HTTP status codes. My understanding was the power of REST came from a large URI space and a small common set of verbs. I do understand the concern about abiguity and have mentioned previously using a response body in addition to the status code. >>Now we may come across situations where those codes are inadequate, >>and in that case we can add another code. > > Yikes, I really hope we don't have to do that. A big appeal of the > REST binding of Atom is that it reuses HTTP. If we start having to > extend HTTP we're in trouble. I do not think we will need to add new status codes. I also doubt we will be able to make a perfect list of every error that could occur for each action. Do you believe that the AtomAPI should specify the exact list of allowed status codes for every action/URI pair? As to the general question if adding new status codes is really extending HTTP, I don't know the answer to that. Maybe we can ask Sam Ruby, since he was involved in the development of WebDAV and they added new status codes. >>>>DELETEing a resource returns a 200 on success whether the >>>>resource existed at the time or not. >>> >>>I think this is a mistake - it's important when a user tries to delete >>>something to tell them whether the delete succeeded or not. >> >>But it did succeed, the resource is not there. > > > What if I blogged something terrible, like "myCatIsATerrorist.txt". I > reconsider, so I go into my handy client software and tell it to > delete "myCatIsATerorist.txt" [sic]. The client posts the delete with > the incorrect URI, but the server merrily returns a "200 OK". I now > think I've deleted the blog entry, but it's still there. This example is a bit contrived since the client is going to be calling DELETE on a URI chosen from a list returned by the server, but I'll ignore that for now since the example does make your point. > > Returning an error on delete is really helpful. Every filesystem-like > API I've ever used returns an error code on delete, I don't see why > this sould be different. > What would you suggest for a status code then? -joe -- http://BitWorking.org http://WellFormedWeb.org From owner-atom-syntax Mon Aug 4 08:16:36 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74FGZqt013048 for ; Mon, 4 Aug 2003 08:16:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74FGZ7h013047 for atom-syntax-bks; Mon, 4 Aug 2003 08:16:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cabernet.nelson.monkey.org (foobar@adsl-63-194-75-26.dsl.snfc21.pacbell.net [63.194.75.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74FGQqt013039 for ; Mon, 4 Aug 2003 08:16:34 -0700 (PDT) (envelope-from nelson@monkey.org) Received: by cabernet.nelson.monkey.org (Postfix, from userid 30193) id 350168C017; Mon, 4 Aug 2003 08:16:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16174.30923.184669.191152@cabernet.nelson.monkey.org> Date: Mon, 4 Aug 2003 08:16:27 -0700 From: Nelson Minar To: Joe Gregorio Cc: atom-syntax@imc.org Subject: Re: REST API questions In-Reply-To: <3F2DD200.5050405@bitworking.org> References: <16172.32172.285580.160099@cabernet.nelson.monkey.org> <3F2C822E.8020807@bitworking.org> <16173.11865.125417.204440@cabernet.nelson.monkey.org> <3F2D3727.1080704@bitworking.org> <16173.15632.958930.845853@cabernet.nelson.monkey.org> <3F2DD200.5050405@bitworking.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think my part of this conversation is drawing to a close. The real point of it was this: >> Using HTTP response codes is part of the magic of REST. But the codes >> are designed for transporting Web documents. I fear in some cases they >> may be ambiguous when applied to an application layered on top of HTTP >> such as an Atom API. This possibility is at the heart of the argument >> for/against REST, so it's useful to get detailed about it. >Wow, I have never heard a rationalization for REST that relied heavily >on the HTTP status codes. My understanding was the power of REST came >from a large URI space and a small common set of verbs. REST, as I understand it, is based on the idea that HTTP semantics are sufficient for building all sorts of complex distributed apps. It's a very appealing argument, because it means our systems can be simple. Part of building distributed apps is proper error handling. HTTP has error handling semantics. The point of all my questions has been to try to evaluate whether those HTTP error semantics are really sufficient to describe our application. My conclusion from our discussion is that it's probably good enough but not great. I don't know if that's a good thing or a bad thing. Other things that come along with the REST approach: HTTP authentication, applications pretty much requiring an HTTP transport. It would be helpful to have a fully fleshed out SOAP proposal to compare to Joe's excellent work. SOAP has a different form of error reporting; using it would require us to define a bunch of SOAP faults for the Atom posting application. On to minutiae of error codes: >Hmm, I had assumed HTTP/1.1, any information you can provide on the >distribution of 1.1 versus 1.0 and things to be concerned about? I think requiring that posting clients understand HTTP/1.1 would be great. Servers should sill try to handle HTTP/1.0 requests when they get them; just serve up HTTP/1.1 error codes anyway. I don't think we can require anything of aggregator clients, but error codes there are much simpler. The main gotcha will be whether any platform's HTTP implementation dictates some HTTP/1.0 behaviour you can't easily override. Ie: if the HTTP stack blows up when it sees a '410 Gone', it'll be hard to write an HTTP/1.1 client for that. I hope this is not a practical problem. >Ok, I misunderstood what you meant by "application error", to be the >program crashed or some other type of internal error when it got that >request. In that case a 5XX would be appropriate, yes? Yes. I meant an application level logic error. >I think in this case, and each of the examples you outline below, there >is no problem with using the closest HTTP status code that matches the >situation and adding in a response body with message details. So the response code for "that URL is not an Atom API" and "that blog does not exist" will be the same? I'm not very happy about this, but maybe I'm overengineering. >I do understand the concern about abiguity and have mentioned previously >using a response body in addition to the status code. I don't think response body message details will be very helpful - they could be displayed to the user, but they're not going to be machine parseable. >Do you believe that the AtomAPI should specify the exact list of allowed >status codes for every action/URI pair? No, we can't enumerate all possible status codes. But we should try to anticipate all the common error conditions and specify what is returned in each case. >> Returning an error on delete is really helpful. >What would you suggest for a status code then? I don't know what HTTP code would be appropriate. (PS - for amusement check out the man page for the Unix system call unlink. The Linux version specifies *14* different error coditions it can return, including some ambiguous cases where a single error code might mean one of two or three different things. And in those 14 conditions I couldn't find a clear statement of which one was "file does not exist", but I think it's ENOENT. Clearly it's possible to overengineer error status codes and end up with a mess!) From owner-atom-syntax Mon Aug 4 09:14:59 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74GExqt015400 for ; Mon, 4 Aug 2003 09:14:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74GExk0015399 for atom-syntax-bks; Mon, 4 Aug 2003 09:14:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74GEwqt015394 for ; Mon, 4 Aug 2003 09:14:58 -0700 (PDT) (envelope-from joe@bitworking.org) Received: from bitworking.org (198-143-226-158.dsl.btitelecom.net [198.143.226.158]) (authenticated) by scandium.sabren.com (8.11.6/8.11.6) with ESMTP id h74GH8D31030; Mon, 4 Aug 2003 12:17:08 -0400 Message-ID: <3F2E879A.3090403@bitworking.org> Date: Mon, 04 Aug 2003 12:19:38 -0400 From: Joe Gregorio User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nelson Minar CC: atom-syntax@imc.org Subject: Re: REST API questions References: <16172.32172.285580.160099@cabernet.nelson.monkey.org> <3F2C822E.8020807@bitworking.org> <16173.11865.125417.204440@cabernet.nelson.monkey.org> <3F2D3727.1080704@bitworking.org> <16173.15632.958930.845853@cabernet.nelson.monkey.org> <3F2DD200.5050405@bitworking.org> <16174.30923.184669.191152@cabernet.nelson.monkey.org> In-Reply-To: <16174.30923.184669.191152@cabernet.nelson.monkey.org> 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: Nelson Minar wrote: > I think my part of this conversation is drawing to a close. The real > point of it was this: > >>>Using HTTP response codes is part of the magic of REST. But the codes >>>are designed for transporting Web documents. I fear in some cases they >>>may be ambiguous when applied to an application layered on top of HTTP >>>such as an Atom API. This possibility is at the heart of the argument >>>for/against REST, so it's useful to get detailed about it. >> >>Wow, I have never heard a rationalization for REST that relied heavily >>on the HTTP status codes. My understanding was the power of REST came >>from a large URI space and a small common set of verbs. > > REST, as I understand it, is based on the idea that HTTP semantics are > sufficient for building all sorts of complex distributed apps. It's a > very appealing argument, because it means our systems can be simple. Agreed. > > Part of building distributed apps is proper error handling. HTTP has > error handling semantics. The point of all my questions has been to > try to evaluate whether those HTTP error semantics are really > sufficient to describe our application. My conclusion from our > discussion is that it's probably good enough but not great. I don't > know if that's a good thing or a bad thing. > > Other things that come along with the REST approach: HTTP > authentication, applications pretty much requiring an HTTP transport. I agree that both of those things come along for free, well, as free as anything can be. However, pending some promised conversations[1] I'm going to reserve judgement on how required/exclusive HTTP authentication is for now. > > It would be helpful to have a fully fleshed out SOAP proposal to > compare to Joe's excellent work. SOAP has a different form of error > reporting; using it would require us to define a bunch of SOAP faults > for the Atom posting application. Yes, in one case you start from scratch and have to build everything yourself with all the work that that entails, or in the other case you start from a known set of codes and end up with possibly vague interpretations. >>I think in this case, and each of the examples you outline below, there >>is no problem with using the closest HTTP status code that matches the >>situation and adding in a response body with message details. > > So the response code for "that URL is not an Atom API" and "that blog > does not exist" will be the same? I'm not very happy about this, but > maybe I'm overengineering. That was just my opinion. Any and all suggestions here, or on the wiki are welcome and will be incorporated into the draft RFC. So if you have an alternate proposal, please let me know. [Camera ready copy being highly preferred :) ] I have also posed the general question of what to return on an error in addition to a status code on this wiki page: http://www.intertwingly.net/wiki/pie/RestEchoApiDiscuss >>I do understand the concern about abiguity and have mentioned previously >>using a response body in addition to the status code. > > I don't think response body message details will be very helpful - > they could be displayed to the user, but they're not going to be > machine parseable. That doesn't necessarily have to be true. Remember that one of my proposed response bodies was an XML file. >>Do you believe that the AtomAPI should specify the exact list of allowed >>status codes for every action/URI pair? > > > No, we can't enumerate all possible status codes. But we should try to > anticipate all the common error conditions and specify what is > returned in each case. Agreed. Thanks, -joe [1] http://www.intertwingly.net/blog/1539.html -- http://BitWorking.org http://WellFormedWeb.org From owner-atom-syntax Mon Aug 4 13:39:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74Kdnqt037003 for ; Mon, 4 Aug 2003 13:39:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74Kdn7e037001 for atom-syntax-bks; Mon, 4 Aug 2003 13:39:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout2.netvision.net.il (mxout2.netvision.net.il [194.90.9.21]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74Kdkqt036975 for ; Mon, 4 Aug 2003 13:39:47 -0700 (PDT) (envelope-from zivca@netvision.net.il) Received: from zivchome ([213.199.128.155]) by mxout2.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HJ400JQY41ERO@mxout2.netvision.net.il> for atom-syntax@imc.org; Mon, 04 Aug 2003 23:39:41 +0300 (IDT) Date: Mon, 04 Aug 2003 22:39:00 +0200 From: Ziv Caspi Subject: RE: REST API questions In-reply-to: <3F2E879A.3090403@bitworking.org> To: "'Joe Gregorio'" , "'Nelson Minar'" Cc: atom-syntax@imc.org Message-id: <001001c35ac8$819524a0$1b431bac@zivchome> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Joe said: > > So the response code for "that URL is not an Atom API" and "that blog > > does not exist" will be the same? I'm not very happy about this, but > > maybe I'm overengineering. > > That was just my opinion. Any and all suggestions > here, or on the wiki are welcome and will be incorporated into the draft RFC. > So if you have an alternate proposal, please let me know. [Camera > ready copy being highly preferred :) ] Whatever you do, please don't make it an error to DELETE a post that's not there: As you (correctly) said earlier, the purpose of DELETE is to reach a state in which the item is gone, and in this case that state has been reached. (Consider another example: that of an item that two individuals try to DELETE at the same time with no coordination.) Ziv Caspi cell: +972-53-668-751 web: http://radio.weblogs.com/0106548/ From owner-atom-syntax Mon Aug 4 13:56:31 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74KuVqt037534 for ; Mon, 4 Aug 2003 13:56:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74KuVjS037533 for atom-syntax-bks; Mon, 4 Aug 2003 13:56:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74KuTqt037526 for ; Mon, 4 Aug 2003 13:56:30 -0700 (PDT) (envelope-from sjenson@google.com) Received: from spf65.corp.google.com (spf65.corp.google.com [10.32.45.65]) by 216-239-45-4.google.com (8.12.9/8.12.6) with ESMTP id h74KuIPH020052; Mon, 4 Aug 2003 13:56:19 -0700 Received: (from root@localhost) by spf65.corp.google.com (8.12.6/8.12.3) id h74KuIUr028032; Mon, 4 Aug 2003 13:56:18 -0700 Message-ID: Date: Mon, 4 Aug 2003 13:56:18 -0700 (PDT) From: Steve Jenson To: Ziv Caspi Subject: Re: REST API questions Cc: Joe Gregorio , Nelson Minar , atom-syntax@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <001001c35ac8$819524a0$1b431bac@zivchome> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon Aug 04 13:39:00 PDT 2003, Ziv Caspi wrote: > Joe said: > > > > So the response code for "that URL is not an Atom API" and "that blog > > > does not exist" will be the same? I'm not very happy about this, but > > > maybe I'm overengineering. > > > > That was just my opinion. Any and all suggestions > > here, or on the wiki are welcome and will be incorporated into the draft > RFC. > > So if you have an alternate proposal, please let me know. [Camera > > ready copy being highly preferred :) ] > > Whatever you do, please don't make it an error to DELETE a post that's not > there: As you (correctly) said earlier, the purpose of DELETE is to reach a > state in which the item is gone, and in this case that state has been > reached. > > (Consider another example: that of an item that two individuals try to > DELETE at the same time with no coordination.) If I try to delete a file off my file system, I get an error. Why should this behave differently? Is my goal to reach a state in which the item is gone or is my goal to take action against a specific resource? I don't really care either way but I would like a status code (success or failure) telling me that the resource did not exist to begin with. Best regards, Steve From owner-atom-syntax Mon Aug 4 16:06:33 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74N6Xqt042713 for ; Mon, 4 Aug 2003 16:06:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74N6Xsb042712 for atom-syntax-bks; Mon, 4 Aug 2003 16:06:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bitsko.slc.ut.us (CPE-65-30-234-116.mn.rr.com [65.30.234.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74N6Vqt042707 for ; Mon, 4 Aug 2003 16:06:31 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id h74N6ZjR011139 for ; Mon, 4 Aug 2003 18:06:36 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h74N6Zpk011135; Mon, 4 Aug 2003 18:06:35 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: Atom-Syntax Subject: Wiki Gardening Chat From: Ken MacLeod Date: 04 Aug 2003 18:06:35 -0500 Message-ID: Lines: 35 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 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: Here is the announcement for the first of hopefully many scheduled topic chat events. Wiki Gardening Thursday, August 7, 2003 at 15:30Z on #echo at irc.freenode.net for 90 minutes, then as participation permits Coordinator: Ken MacLeod The topic of this chat is to begin the effort of organizing and refactoring the wiki. The goals will be to prioritize specific refactorings, identify potential organizational techniques, and perform more significant refactorings with reviewers available for immediate sanity checks. Of the specific refactorings, some will be highlighted as suggestions for general and ongoing refactoring of the wiki, to be used whenever anyone is wiki gardening. Further details and suggestions can be added to the wiki at http://intertwingly.net/wiki/pie/WikiGardening Just to be clear, wiki gardening happens all the time. The purpose of a scheduled chat is to focus on specific refactoring goals, particularly those where individuals may feel uncomfortable making larger refactorings. This chat is not a technical event. Hopefully technical chat events will also soon be appearing. Keep an eye out on the FrontPage and this mailing list for future chats. -- Ken MacLeod From owner-atom-syntax Mon Aug 4 21:45:59 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h754jxqt057517 for ; Mon, 4 Aug 2003 21:45:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h754jxGb057516 for atom-syntax-bks; Mon, 4 Aug 2003 21:45:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h754jwqt057511 for ; Mon, 4 Aug 2003 21:45:58 -0700 (PDT) (envelope-from joe@bitworking.org) Received: from bitworking.org (adsl-80-204-233.rdu.bellsouth.net [65.80.204.233]) (authenticated) by scandium.sabren.com (8.11.6/8.11.6) with ESMTP id h754mGZ14043 for ; Tue, 5 Aug 2003 00:48:16 -0400 Message-ID: <3F2F3684.6070002@bitworking.org> Date: Tue, 05 Aug 2003 00:45:56 -0400 From: Joe Gregorio User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Introspection and RSD 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: Dare Obasanjo has posted some comments on draft 06 of the AtomAPI [1]. His first comment is about Introspection: "Too much indirection when attempting to discover information about the services a site supports. I have to hit the website's homepage which has a LINK element which points to an RSD file which to an introspection file that describes the features supported by the website before I can figure out which Atom API services teh website supports. At least one of those steps is unnecessary. I don't see why the link element can't directly point to the introspection file." I agree that there are too many levels of indirection. On one hand the AtomAPI initally started with only the Introspection file, RSD was added later. On the other hand RSD is already deployed for editing tools and it seems a shame to ignore that installed base. What do you think, should we drop RSD, or maybe put all the functionality of the Introspection file into an RSD file? Thanks, -joe [1] http://www.kuro5hin.org/story/2003/8/3/133458/0512 -- http://BitWorking.org http://WellFormedWeb.org From owner-atom-syntax Tue Aug 5 04:49:26 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75BnQqt001218 for ; Tue, 5 Aug 2003 04:49:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75BnQuU001217 for atom-syntax-bks; Tue, 5 Aug 2003 04:49:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from xbox.wkearney.com (xbox.wkearney.com [66.92.145.79]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75BnOqt001211 for ; Tue, 5 Aug 2003 04:49:24 -0700 (PDT) (envelope-from wkearney99@hotmail.com) Received: from media (media.wkearney.com [192.168.12.32]) by xbox.wkearney.com (8.12.5/8.12.5) with SMTP id h75AknwW003584; Tue, 5 Aug 2003 06:46:50 -0400 Message-ID: <013401c35b47$96180cb0$200ca8c0@wkearney.com> From: "Bill Kearney" To: "Joe Gregorio" , References: <3F2F3684.6070002@bitworking.org> Subject: Re: Introspection and RSD Date: Tue, 5 Aug 2003 07:49:10 -0400 Organization: http://www.ideaspace.net/users/wkearney/foaf.xrdf 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 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Is there a reason not to allow for both? I'm not convinced it's a good idea to depend on the HTML pages containing the correct info. The people responsible for the 'look and feel' of the HTML pages may or may not be to the same people responsible for the maintenance and operation of backend interfaces. So expecting the HTML people to put up with and properly maintain what might be a LOT of metadata tags in the head section is asking for trouble. So using an external document seems like a much safer proposition. As to whether the format should be RSD, well, that's another thread. -Bill Kearney ----- Original Message ----- From: "Joe Gregorio" To: Sent: Tuesday, August 05, 2003 12:45 AM Subject: Introspection and RSD > > Dare Obasanjo has posted some comments on draft 06 of the > AtomAPI [1]. His first comment is about Introspection: > > "Too much indirection when attempting to discover information about the > services a site supports. I have to hit the website's homepage which has > a LINK element which points to an RSD file which to an introspection > file that describes the features supported by the website before I can > figure out which Atom API services teh website supports. At least one of > those steps is unnecessary. I don't see why the link element can't > directly point to the introspection file." > > I agree that there are too many levels of indirection. On > one hand the AtomAPI initally started with only the Introspection > file, RSD was added later. On the other hand RSD is already > deployed for editing tools and it seems a shame to ignore > that installed base. > > What do you think, should we drop RSD, or maybe put all the > functionality of the Introspection file into an RSD file? > > Thanks, > -joe > > [1] http://www.kuro5hin.org/story/2003/8/3/133458/0512 > > -- > http://BitWorking.org > http://WellFormedWeb.org > > > From owner-atom-syntax Tue Aug 5 13:41:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75KfXqt035830 for ; Tue, 5 Aug 2003 13:41:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75KfXW8035829 for atom-syntax-bks; Tue, 5 Aug 2003 13:41:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout2.netvision.net.il (mxout2.netvision.net.il [194.90.9.21]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75KfVqt035812 for ; Tue, 5 Aug 2003 13:41:31 -0700 (PDT) (envelope-from zivca@netvision.net.il) Received: from zivchome ([213.199.128.157]) by mxout2.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HJ5000J2YSJ79@mxout2.netvision.net.il> for atom-syntax@imc.org; Tue, 05 Aug 2003 23:41:25 +0300 (IDT) Date: Tue, 05 Aug 2003 22:41:04 +0200 From: Ziv Caspi Subject: RE: REST API questions In-reply-to: To: "'Steve Jenson'" Cc: "'Joe Gregorio'" , "'Nelson Minar'" , atom-syntax@imc.org Message-id: <000c01c35b91$eeec8790$0e431bac@zivchome> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Steve Jenson wrote: > If I try to delete a file off my file system, I get an error. Why > should this behave differently? Because file system APIs got it wrong. They eagerly return error codes that force clients to handle non-error conditions. Consider an uninstall application that tries to delete an application file: should it specifically handle file-not-found cases? > Is my goal to reach a state in which > the item is gone or is my goal to take action against a specific > resource? Generally, when you can design your API to be state-oriented (or should I say goal-oriented) rather than action-oriented, you're making writing correct clients easier. > I don't really care either way but I would like a status > code (success or failure) telling me that the resource did not exist > to begin with. It's fine to return a success code that also says that the server had no work to do. I wonder what the HTTP equivalent to S_FALSE is... Ziv Caspi cell: +972-53-668-751 web: http://radio.weblogs.com/0106548/ From owner-atom-syntax Wed Aug 6 09:02:20 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76G2Kqt030180 for ; Wed, 6 Aug 2003 09:02:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h76G2KSQ030179 for atom-syntax-bks; Wed, 6 Aug 2003 09:02:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41210.mail.yahoo.com (web41210.mail.yahoo.com [66.218.93.43]) by above.proper.com (8.12.9/8.12.8) with SMTP id h76G2Jqt030172 for ; Wed, 6 Aug 2003 09:02:19 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20030806160215.78660.qmail@web41210.mail.yahoo.com> Received: from [12.228.53.136] by web41210.mail.yahoo.com via HTTP; Wed, 06 Aug 2003 09:02:15 PDT Date: Wed, 6 Aug 2003 09:02:15 -0700 (PDT) From: Dare Obasanjo Subject: Re: Introspection and RSD To: atom-syntax@imc.org 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: Bill, Agreed. I don't believe anyone is saying that all the metadata should be in the HTML page. Instead what I asked, which Joe correctly interpreted is whether there is a need for both an RSD file and an Introspection file. It doesn't seem that way to me and there is no reason why the functionality of either one cannot be collapsed into the other. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #59 I will never build a sentient computer smarter than I am. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From owner-atom-syntax Wed Aug 6 21:03:18 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7743Hqt062709 for ; Wed, 6 Aug 2003 21:03:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7743H6m062708 for atom-syntax-bks; Wed, 6 Aug 2003 21:03:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7743Gqt062701 for ; Wed, 6 Aug 2003 21:03:16 -0700 (PDT) (envelope-from joe@bitworking.org) Received: from bitworking.org (adsl-80-204-233.rdu.bellsouth.net [65.80.204.233]) (authenticated) by scandium.sabren.com (8.11.6/8.11.6) with ESMTP id h7745sJ13303 for ; Thu, 7 Aug 2003 00:05:55 -0400 Message-ID: <3F31CF83.9090809@bitworking.org> Date: Thu, 07 Aug 2003 00:03:15 -0400 From: Joe Gregorio User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: draft-gregorio-07.html 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: Draft 07 of the AtomAPI has been posted: http://bitworking.org/rfc/draft-gregorio-07.html Changes from the previous version: 1. Removed the use of the RSD file for auto-discovery. 2. Changed copyright until a final standards body is chosen. 3. Changed query parameters for the search facet to all begin with atom- to avoid name collisions. 4. Updated all the Entries to follow the 0.2 version. 5. Changed the format of the search results and template file to a pure element based syntax. I will update the discussion on the wiki tomorrow to archive suggestions that have been incorporated into this draft. Thanks, -joe -- http://BitWorking.org http://WellFormedWeb.org From owner-atom-syntax Wed Aug 6 21:21:15 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h774LFqt063745 for ; Wed, 6 Aug 2003 21:21:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h774LFpC063743 for atom-syntax-bks; Wed, 6 Aug 2003 21:21:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from csm.chalko.com (034.148-60-66-fuji-dsl.static.surewest.net [66.60.148.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h774LDqt063736 for ; Wed, 6 Aug 2003 21:21:13 -0700 (PDT) (envelope-from nick@chalko.com) Received: from chalko.com (unknown [192.168.57.254]) by csm.chalko.com (Postfix) with ESMTP id 92B31FF84 for ; Wed, 6 Aug 2003 21:21:16 -0700 (PDT) Message-ID: <3F31D3B1.9040701@chalko.com> Date: Wed, 06 Aug 2003 21:21:05 -0700 From: Nick Chalko User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030612 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: draft-gregorio-07.html References: <3F31CF83.9090809@bitworking.org> In-Reply-To: <3F31CF83.9090809@bitworking.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050907010702070809090005" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms050907010702070809090005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A few quick things I noticed. 5.8 Adding Comments spelling /corrent /should be /correct / 5.8.1.2 Atom Feed Auto-Discovery There is a element in each Entry that is used to provide the location of the URI that accepts comment POSTs. This is providing the same information as the link tag does in HTML however none of the example's show the comment element. R, Nick > --------------ms050907010702070809090005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPDCC AvwwggJloAMCAQICAwma2jANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDMyODA4MzA0MFoXDTA0MDMyNzA4MzA0MFowQTEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEeMBwGCSqGSIb3DQEJARYPbmlja0Bj aGFsa28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApfM/4tyKTcqSwSFT PuZvHksz10JPmvRS6YGWO4LNT8qVuZf66z/dusmN2/a4gW8A5JibxEqyUdOxkBnHAXQKwPpQ aOeFSBIaPPeBWk1MicJ9H+EA0LwX6B5kG4bKDB+qn32bWcoGIu5z+NEERRgZ49SSAKAJYggM OmMb7CIWruaMaaZRsiirvuSpG+8HiOXHFNfeCB4+iD5/3DDHOqQbl/KwBR9aN/QBHLc7bqpa y09aqX8RPTNlJfVArj6LF+cn5WtN4YQUExztzrE0axmLDAZYN+nr3izPoBhiefE8A82MUFe7 PJnmqEROakbyOjPS0imT+WSnxnXmYLMQ7G/08wIDAQABoywwKjAaBgNVHREEEzARgQ9uaWNr QGNoYWxrby5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBesYrZZ3v0ccUI dxxS9F3Bqpuhak5rPYFYqfP98FK918ams/3E51rC2Vu8S2D3ns8dFcpdUpsUDZCpjmtviqi/ SYsJMv8FRv05wtyZWBmMfnMGEqZNLKeYKAchmeQZc7H+v50N3ZDU19UPfq03TkZRORTcIGwi SclaF2PqXiJPkTCCAvwwggJloAMCAQICAwma2jANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UE BhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYD VQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9Q ZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDMyODA4MzA0MFoXDTA0MDMy NzA4MzA0MFowQTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEeMBwGCSqGSIb3 DQEJARYPbmlja0BjaGFsa28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA pfM/4tyKTcqSwSFTPuZvHksz10JPmvRS6YGWO4LNT8qVuZf66z/dusmN2/a4gW8A5JibxEqy UdOxkBnHAXQKwPpQaOeFSBIaPPeBWk1MicJ9H+EA0LwX6B5kG4bKDB+qn32bWcoGIu5z+NEE RRgZ49SSAKAJYggMOmMb7CIWruaMaaZRsiirvuSpG+8HiOXHFNfeCB4+iD5/3DDHOqQbl/Kw BR9aN/QBHLc7bqpay09aqX8RPTNlJfVArj6LF+cn5WtN4YQUExztzrE0axmLDAZYN+nr3izP oBhiefE8A82MUFe7PJnmqEROakbyOjPS0imT+WSnxnXmYLMQ7G/08wIDAQABoywwKjAaBgNV HREEEzARgQ9uaWNrQGNoYWxrby5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQBesYrZZ3v0ccUIdxxS9F3Bqpuhak5rPYFYqfP98FK918ams/3E51rC2Vu8S2D3ns8dFcpd UpsUDZCpjmtviqi/SYsJMv8FRv05wtyZWBmMfnMGEqZNLKeYKAchmeQZc7H+v50N3ZDU19UP fq03TkZRORTcIGwiSclaF2PqXiJPkTCCAzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEw DQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNV BAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAwMDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQG EwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNV BAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1Bl cnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZgpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCj bZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqdknWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M8 8Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFpAgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYD VQQDExFQcml2YXRlTGFiZWwxLTI5NzASBgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIB BjANBgkqhkiG9w0BAQQFAAOBgQAxsUtHXfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7 BDm6/ObyJOuR+r3sDSo491BVqGz3Da1MG7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5 edDqLiXdiuT82w0fnQLzWtvKPPZE6iZph39Ins6ln+eE2MliYq0FxjGCA9UwggPRAgEBMIGa MIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBl IFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMx KDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwma2jAJBgUrDgMC GgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4 MDcwNDIxMDVaMCMGCSqGSIb3DQEJBDEWBBT7aD91Qf2kaCdfhEKr0wh5vU7GrjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBqwYJKwYBBAGCNxAEMYGdMIGaMIGSMQswCQYDVQQG EwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNV BAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1Bl cnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwma2jCBrQYLKoZIhvcNAQkQAgsxgZ2g gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCZraMA0GCSqG SIb3DQEBAQUABIIBAD4KIU0ji4xz3GH3V9eWIokhqI3iH1hO5TF8qoJHSVdLSkXBfYFgAoIA s+73jzxFvEbBtOdnIb9bKW3euRwgZUmGI3Yi57NqnhjhF8X2Z0LOcxy8Z9K43LDC+7o9kLbx jALvwq7NtydMZGFy0mTOvFldkTgAza6lMSDCAJftj/VC/e8ktS8CpNohMfVYSTJT96pc7U4R COkkyrVcuvm45ZrDJreEscFHyb+WeeZr2Ed9DcGArb5daDQ97Y4xmUXkwvjNgTdjEPRFjDPX /6A3f6mM8hvQeoa3Yclpd2Wga/ZLENmuxA0hzQXAv7qMhjjUOjmnaFZXTO2QV0CFVwN+OfIA AAAAAAA= --------------ms050907010702070809090005-- From owner-atom-syntax Thu Aug 7 06:38:19 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77DcJqt018455 for ; Thu, 7 Aug 2003 06:38:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77DcJ5l018454 for atom-syntax-bks; Thu, 7 Aug 2003 06:38:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from circumtech.com (amber.circumtech.com [168.100.173.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77DcIqt018446 for ; Thu, 7 Aug 2003 06:38:18 -0700 (PDT) (envelope-from daniel@circumtech.com) Received: from 192.168.1.100 (67.85.87.74) by circumtech.com with ESMTP (Eudora Internet Mail Server 3.1.4) for ; Thu, 7 Aug 2003 09:38:19 -0400 Date: Thu, 7 Aug 2003 09:38:37 -0400 From: Daniel Berlinger Subject: Re: draft-gregorio-07.html To: atom-syntax@imc.org X-Priority: 3 In-Reply-To: <3F31CF83.9090809@bitworking.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 2.0 (Blindsider) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > http://bitworking.org/rfc/draft-gregorio-07.html Joe had written me saying he would bring up RSD yes or no issues to see what the community thinks. Everyone agreed that both are not necessary and I wrote an example RSD file that exposes the same "introspection" as in Joe's RFC -- and in some ways is more flexible than the introspection file. Further, RSD is already supported by quite a few tools, from auto discovery through to parsing. I thought the obvious choice was RSD, but Joe raised what could be a real issue with me, which is he was concerned about using a spec controlled by one person (namely me :). Of course, the format was always disclaimed, and was a commmunity effort from the beginning. I told Joe that I'm happy to give the whole thing to the community through whatever means the community desires, he suggested making it an IETF RFC, I suggested a Creative Commons license since niether one of us was certain how much was involved with the RFC (or at least Joe said he's learning now) I assumed there was no rush to decide. Imagine my surprise, when after the tepid discussion that took place on this list, the latest RFC has removed RSD. My question is simple... why is a new format for "introspection" required here? Why make the tool vendors rewrite their stuff to deal with this aspect as well? Many of the engine companies including SixApart, UserLand, etc. have supported or promised to support (Blogger) RSD. In a blog sense, it is already "widely deployed"... so why the switch? d. From owner-atom-syntax Thu Aug 7 07:54:48 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77Eslqt025278 for ; Thu, 7 Aug 2003 07:54:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77EslU1025276 for atom-syntax-bks; Thu, 7 Aug 2003 07:54:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77Eskqt025267 for ; Thu, 7 Aug 2003 07:54:46 -0700 (PDT) (envelope-from joe@bitworking.org) Received: from bitworking.org (198-143-226-158.dsl.btitelecom.net [198.143.226.158]) (authenticated) by scandium.sabren.com (8.11.6/8.11.6) with ESMTP id h77EvQo25963; Thu, 7 Aug 2003 10:57:26 -0400 Message-ID: <3F326973.8050903@bitworking.org> Date: Thu, 07 Aug 2003 11:00:03 -0400 From: Joe Gregorio User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Berlinger CC: atom-syntax@imc.org Subject: Re: draft-gregorio-07.html 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: Daniel, Sorry for the unpleasant suprise. As you mention I did ask here and on the wiki. I saw a consensus that too many of levels were involved. I didn't read a clear concensus on which file to remove, but did see a preference for dropping RSD over the Introspection file. Yes, it was very close and someone else may read the same comments and interpret them the other way. In spite of that and in the interest of keeping the spec moving forward I went with that preference and removed RSD. This is just a draft. If a concensus does emerge around using RSD over the Introspection file it can be changed back. Daniel Berlinger wrote: > >>http://bitworking.org/rfc/draft-gregorio-07.html > > > Joe had written me saying he would bring up RSD yes or no issues to > see what the community thinks. Everyone agreed that both are > not necessary and I wrote an example RSD file that exposes the > same "introspection" as in Joe's RFC -- > and in some ways is more flexible than the introspection file. I'm sorry, but I didn't see that example, could you provide a link to it? Thanks, -joe -- http://BitWorking.org http://WellFormedWeb.org From owner-atom-syntax Thu Aug 7 09:22:20 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77GMKqt032203 for ; Thu, 7 Aug 2003 09:22:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77GMK5E032202 for atom-syntax-bks; Thu, 7 Aug 2003 09:22:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cabernet.nelson.monkey.org (foobar@adsl-63-194-75-26.dsl.snfc21.pacbell.net [63.194.75.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77GMJqt032197 for ; Thu, 7 Aug 2003 09:22:19 -0700 (PDT) (envelope-from nelson@monkey.org) Received: by cabernet.nelson.monkey.org (Postfix, from userid 30193) id 2EC608C017; Thu, 7 Aug 2003 09:22:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16178.31932.163836.839864@cabernet.nelson.monkey.org> Date: Thu, 7 Aug 2003 09:22:20 -0700 From: Nelson Minar To: atom-syntax@imc.org Subject: comments on Atom 0.2 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I hacked up an Atom 0.2 feed today and blogged some comments: http://www.nelson.monkey.org/~nelson/weblog/tech/blosxom/atomFeed.html Three issues seem important to resolve. Is discussing them on this mailing list sufficient, or do I need to wade into the Wiki? The

element specfies it's plain text, no escaped HTML. What happens if I want an HTML entity in there? Am I not allowed? I think

and similar elements should have the same content encoding attribute that does. elements seem too wordy. is redundant with in Blosxom. I don't see why I need two timestamps (, ), identical except for timezone. Recommendation: make and optional (if is missing, substiute ). is optional. Some lawyer should reassure us that its omission does not imply the feed is not copyrighted. I'm happy with implicit copyright and would rather not waste 50 bytes in every single download. From owner-atom-syntax Thu Aug 7 09:27:51 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77GRpqt032364 for ; Thu, 7 Aug 2003 09:27:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77GRpNI032363 for atom-syntax-bks; Thu, 7 Aug 2003 09:27:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from circumtech.com (amber.circumtech.com [168.100.173.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77GRoqt032357 for ; Thu, 7 Aug 2003 09:27:50 -0700 (PDT) (envelope-from daniel@circumtech.com) Received: from 10.0.0.140 (63.78.64.148) by circumtech.com with ESMTP (Eudora Internet Mail Server 3.1.4); Thu, 7 Aug 2003 12:27:52 -0400 Date: Thu, 7 Aug 2003 12:28:04 -0400 From: Daniel Berlinger Subject: Re: draft-gregorio-07.html To: Joe Gregorio cc: atom-syntax@imc.org X-Priority: 3 In-Reply-To: <3F326973.8050903@bitworking.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 2.0 (Blindsider) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Joe, Could you point me to the discussion on the Wiki? (or anywhere else the issue's been discussed) I can't seem to find it, or any preference one way or the other. Is anyone representing the tools people? Is there a technical benefit to the introspection stuff? I remind again that the Blogger folks who created it are willing to support RSD. I understand that the RFC reflects what you believe the concensus is, and that nothing is set in stone... I just can't seem to find the sources of concencus, or even a clear conversation about the technical merits of either. Thanks, d. > Daniel, > Sorry for the unpleasant suprise. As you mention I did ask here > and on the wiki. I saw a consensus that too many of levels were involved. > I didn't read a clear concensus on which file to remove, but did > see a preference for dropping RSD over the Introspection > file. Yes, it was very close and someone else may read the same > comments and interpret them the other way. In spite of that and in the interest > of keeping the spec moving forward I went with that preference and removed RSD. > This is just a draft. If a concensus does emerge around > using RSD over the Introspection file it can be changed > back. > > Daniel Berlinger wrote: > > > >>http://bitworking.org/rfc/draft-gregorio-07.html > > > > > > Joe had written me saying he would bring up RSD yes or no issues to > > see what the community thinks. Everyone agreed that both are > > not necessary and I wrote an example RSD file that exposes the > > same "introspection" as in Joe's RFC -- > > and in some ways is more flexible than the introspection file. > > I'm sorry, but I didn't see that example, could you provide a link > to it? > > Thanks, > -joe > From owner-atom-syntax Thu Aug 7 09:52:24 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77GqOqt033247 for ; Thu, 7 Aug 2003 09:52:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77GqOxH033246 for atom-syntax-bks; Thu, 7 Aug 2003 09:52:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77GqNqt033240 for ; Thu, 7 Aug 2003 09:52:23 -0700 (PDT) (envelope-from joe@bitworking.org) Received: from bitworking.org (198-143-226-158.dsl.btitelecom.net [198.143.226.158]) (authenticated) by scandium.sabren.com (8.11.6/8.11.6) with ESMTP id h77Gt4v01257; Thu, 7 Aug 2003 12:55:04 -0400 Message-ID: <3F328504.8060808@bitworking.org> Date: Thu, 07 Aug 2003 12:57:40 -0400 From: Joe Gregorio User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Berlinger CC: atom-syntax@imc.org Subject: Re: draft-gregorio-07.html 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: Daniel Berlinger wrote: > Joe, > > Could you point me to the discussion on the Wiki? > (or anywhere else the issue's been discussed) I can't > seem to find it, or any preference one way or the other. > > Is anyone representing the tools people? Is there a > technical benefit to the introspection stuff? I remind > again that the Blogger folks who created it are willing to support RSD. > > I understand that the RFC reflects what you believe the > concensus is, and that nothing is set in stone... I just > can't seem to find the sources of concencus, or even a > clear conversation about the technical merits of either. I went back and re-read and there is precious little to quote on the wiki. I also realized some feedback was via private email, which I will not quote. So. Let me change what I stated earlier about 'slight preference' to be: 1. There is no consensus on RSD vs Introspection. 2. I made a judgement call. 3. If a consensus does emerge I will change the RFC to reflect that consenus. I would really like to see a technical discussion erupt from here. Thanks, -joe From owner-atom-syntax Thu Aug 7 11:06:47 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77I6lqt035634 for ; Thu, 7 Aug 2003 11:06:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77I6lSQ035633 for atom-syntax-bks; Thu, 7 Aug 2003 11:06:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from circumtech.com (amber.circumtech.com [168.100.173.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77I6kqt035628 for ; Thu, 7 Aug 2003 11:06:46 -0700 (PDT) (envelope-from daniel@circumtech.com) Received: from 10.0.0.140 (63.78.64.148) by circumtech.com with ESMTP (Eudora Internet Mail Server 3.1.4) for ; Thu, 7 Aug 2003 14:06:49 -0400 Date: Thu, 7 Aug 2003 14:07:06 -0400 From: Daniel Berlinger Subject: Re: draft-gregorio-07.html To: atom-syntax@imc.org X-Priority: 3 In-Reply-To: <3F328504.8060808@bitworking.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 2.0 (Blindsider) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I went back and re-read and there is precious little > to quote on the wiki. I also realized some feedback > was via private email, which I will not quote. That was exactly the back channel sort of thing I thought you were trying to avoid, and which I feared. I specifically avoided saying anything about my thoughts in the hopes that it would not be the case. > So. > > Let me change what I stated earlier about 'slight preference' to be: > > 1. There is no consensus on RSD vs Introspection. > 2. I made a judgement call. > 3. If a consensus does emerge I will change the RFC to reflect that consenus. > > I would really like to see a technical discussion > erupt from here. Yeah, me to. Except why should anyone bother? You've made a judgment call, the unnamed folks have what they want, and the tools guys pick up the cost. I now have to push uphill against an unknown group of folks rather simply ask why a new format is required, when there is a supported format used by this community? Want to flatten the field again Joe? Pull the Introspection section from the RFC, with a "To Be Decided" and then let's see where things stand. Yuck. d. From owner-atom-syntax Thu Aug 7 11:29:14 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77ITEqt037199 for ; Thu, 7 Aug 2003 11:29:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77ITEig037198 for atom-syntax-bks; Thu, 7 Aug 2003 11:29:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77ITDqt037193 for ; Thu, 7 Aug 2003 11:29:13 -0700 (PDT) (envelope-from joe@bitworking.org) Received: from bitworking.org (198-143-226-158.dsl.btitelecom.net [198.143.226.158]) (authenticated) by scandium.sabren.com (8.11.6/8.11.6) with ESMTP id h77IVtT07999 for ; Thu, 7 Aug 2003 14:31:55 -0400 Message-ID: <3F329BB6.1080900@bitworking.org> Date: Thu, 07 Aug 2003 14:34:30 -0400 From: Joe Gregorio User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: [Fwd: Re: draft-gregorio-07.html] 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: Daniel Berlinger wrote: > > >>I went back and re-read and there is precious little >>to quote on the wiki. I also realized some feedback >>was via private email, which I will not quote. > > > That was exactly the back channel sort of thing I > thought you were trying to avoid, and which I > feared. I specifically avoided saying anything > about my thoughts in the hopes that it would not be the case. I do not like back channel stuff either, and that is why I backed off my statement of there being a preference. > Yeah, me to. Except why should anyone bother? You've made a > judgment call, the unnamed folks have what they want, and the tools guys pick up the cost. > > I now have to push uphill against an unknown group of folks rather > simply ask why a new format is required, when there is a supported > format used by this community? > > Want to flatten the field again Joe? Pull the Introspection section > from the RFC, with a "To Be Decided" and then let's see where things stand. I DO NOT CARE WHICH FORMAT IS USED. Can I make that any clearer? The wild accusations of a conspiracy aren't going to help you make your case and are at least giving me second thoughts about putting RSD in there to begin with. Can we please have a show of hands on what people prefer, either RSD or Introspection, and the next rev of the spec will reflect that vote. I will only go with feedback that is "on the record", ie on the mailing list or on the wiki. Thanks, -joe -- http://BitWorking.org http://WellFormedWeb.org -- http://BitWorking.org http://WellFormedWeb.org From owner-atom-syntax Thu Aug 7 11:27:38 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77IRcqt036849 for ; Thu, 7 Aug 2003 11:27:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77IRceG036847 for atom-syntax-bks; Thu, 7 Aug 2003 11:27:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from anthrax.middlebury.edu (anthrax.middlebury.edu [140.233.2.72]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77IRaqt036834 for ; Thu, 7 Aug 2003 11:27:36 -0700 (PDT) (envelope-from mceglows@middlebury.edu) Received: from jaguar.middlebury.edu [140.233.2.102] by anthrax.middlebury.edu with XWall v3.27 ; Thu, 7 Aug 2003 14:27:31 -0400 Received: from middlebury.edu (140.233.69.164 [140.233.69.164]) by jaguar.middlebury.edu with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q2D3TFKV; Thu, 7 Aug 2003 14:15:03 -0400 Date: Thu, 7 Aug 2003 14:28:27 -0400 Subject: xml:lang attribute Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Maciej Ceglowski To: Atom Syntax Content-Transfer-Encoding: 7bit In-Reply-To: <3F31D3B1.9040701@chalko.com> Message-Id: X-Mailer: Apple Mail (2.552) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This was discussed in the Wiki, but didn't make it into the .02 snapshot. Atom feeds need to have an xml:lang attribute at the feed level, which can be overriden at lower levels (content, for example) if necessary. Right now, there are 'title' elements at the feed and entry level, for which the language attribute is undefined. If the feed itself had an xml:lang attribute, it could cascade down to child elements. I believe the consensus on the Wiki was to allow for xml:lang values of 'unknown' to grandfather in tools that don't export language metadata. If anyone knows of a better place to post this comment, I'd love to know. I'm lost at this point, between the Wiki and mailing list, and apparently lots of back-channel discussion. -Maciej Ceglowski From owner-atom-syntax Thu Aug 7 11:39:54 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77Idsqt037570 for ; Thu, 7 Aug 2003 11:39:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77IdsAp037569 for atom-syntax-bks; Thu, 7 Aug 2003 11:39:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cabernet.nelson.monkey.org (foobar@adsl-63-194-75-26.dsl.snfc21.pacbell.net [63.194.75.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77Idrqt037564 for ; Thu, 7 Aug 2003 11:39:53 -0700 (PDT) (envelope-from nelson@monkey.org) Received: by cabernet.nelson.monkey.org (Postfix, from userid 30193) id B68738C017; Thu, 7 Aug 2003 11:39:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16178.40186.718225.810081@cabernet.nelson.monkey.org> Date: Thu, 7 Aug 2003 11:39:54 -0700 From: Nelson Minar To: Joe Gregorio Cc: atom-syntax@imc.org Subject: Re: [Fwd: Re: draft-gregorio-07.html] In-Reply-To: <3F329BB6.1080900@bitworking.org> References: <3F329BB6.1080900@bitworking.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm part of the shadowy conspiracy of backchannel people. My sole comment to Joe, who is too polite to quote me, was "I'd never heard of RSD before seeing it in Atom". I don't know if that's a sign of my ignorance or of RSD obscurity. I haven't looked closely enough at discovery in Atom to know what's right. Would WSDL be applicable? I know it would be in a SOAP case, and I've heard rumours it should be in REST-like APIs. From owner-atom-syntax Thu Aug 7 11:47:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77Il3qt037827 for ; Thu, 7 Aug 2003 11:47:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77Il3ad037826 for atom-syntax-bks; Thu, 7 Aug 2003 11:47:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77Il1qt037819 for ; Thu, 7 Aug 2003 11:47:01 -0700 (PDT) (envelope-from sjenson@google.com) Received: from spf65.corp.google.com (spf65.corp.google.com [10.32.45.65]) by 216-239-45-4.google.com (8.12.9/8.12.6) with SMTP id h77Ikwju019358 for ; Thu, 7 Aug 2003 11:46:58 -0700 Message-ID: Date: Thu, 7 Aug 2003 11:46:58 -0700 (PDT) From: Steve Jenson To: atom-syntax@imc.org Subject: Re: draft-gregorio-07.html Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu Aug 07 11:07:06 PDT 2003, Daniel Berlinger wrote: > > I went back and re-read and there is precious little > > to quote on the wiki. I also realized some feedback > > was via private email, which I will not quote. > > That was exactly the back channel sort of thing I thought you were trying to avoid, and which I feared. I specifically avoided saying anything about my thoughts in the hopes that it would not be the case. > > > So. > > > > Let me change what I stated earlier about 'slight preference' to be: > > > > 1. There is no consensus on RSD vs Introspection. > > 2. I made a judgement call. > > 3. If a consensus does emerge I will change the RFC to reflect that consenus. > > > > I would really like to see a technical discussion > > erupt from here. > > Yeah, me to. Except why should anyone bother? You've made a judgment call, the unnamed folks have what they want, and the tools guys pick up the cost. > > I now have to push uphill against an unknown group of folks rather simply ask why a new format is required, when there is a supported format used by this community? > > Want to flatten the field again Joe? Pull the Introspection section from the RFC, with a "To Be Decided" and then let's see where things stand. > > Yuck. My understanding of RSD (having read the spec and having implemented it for Blogger) and my understanding of the proposed Atom introspection leads me to believe that the two intersect in one major way: the entry point for the api. RSD specifies a single entry point, and Atom can specify multiple entry points. Also, I had thought (maybe I was dreaming) that the Atom introspection would be expanded to give details about the extensions those entry-points support. Given that RSD can be extended via XML Namespaces (thank you, Daniel!), it seems to make sense to try and move the proposed Atom API Introspection contents into RSD as a module. -steve From owner-atom-syntax Thu Aug 7 11:46:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77Ikmqt037813 for ; Thu, 7 Aug 2003 11:46:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77IkmnA037812 for atom-syntax-bks; Thu, 7 Aug 2003 11:46:48 -0700 (PDT) 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.9/8.12.8) with ESMTP id h77Ikmqt037805 for ; Thu, 7 Aug 2003 11:46:48 -0700 (PDT) (envelope-from brent@ranchero.com) Received: from ranchero.com (12-228-169-112.client.attbi.com[12.228.169.112](untrusted sender)) by attbi.com (rwcrmhc11) with SMTP id <2003080718464301300hvokqe>; Thu, 7 Aug 2003 18:46:43 +0000 Date: Thu, 7 Aug 2003 11:46:40 -0700 Subject: Re: [Fwd: Re: draft-gregorio-07.html] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Brent Simmons To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <3F329BB6.1080900@bitworking.org> Message-Id: <7B560093-C907-11D7-B807-000393BA4E08@ranchero.com> X-Mailer: Apple Mail (2.552) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thursday, August 7, 2003, at 11:34 AM, Joe Gregorio wrote: > Can we please have a show of hands on what people prefer, either RSD > or Introspection, and the next rev of the spec will reflect that vote. > I will only go with feedback that is "on the record", ie on the > mailing > list or on the wiki. I prefer RSD, because: 1. Authors of editing tools have already written code to parse RSD files. 2. Movable Type and Radio UserLand and others already generate RSD files. -Brent From owner-atom-syntax Thu Aug 7 12:05:52 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77J5qqt038457 for ; Thu, 7 Aug 2003 12:05:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77J5qjq038456 for atom-syntax-bks; Thu, 7 Aug 2003 12:05:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bitsko.slc.ut.us (CPE-65-30-234-116.mn.rr.com [65.30.234.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77J5oqt038450 for ; Thu, 7 Aug 2003 12:05:50 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id h77J6qjR002709 for ; Thu, 7 Aug 2003 14:06:52 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h77J6q7q002702; Thu, 7 Aug 2003 14:06:52 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: Atom-Syntax Subject: Wiki Gardening Chat From: Ken MacLeod Date: 07 Aug 2003 14:06:52 -0500 Message-ID: Lines: 479 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 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: We held our first WikiGardening chat today. Our goals were to prioritize specific refactorings, identify organizational techniques, perform refactorings, and schedule another meeting. We didn't get to prioritizing the refactorings or actually performing any refactorings today. The specific refactorings and organizational techniques we identified are on the WikiGardening page, with a snapshot of those below. Anyone can add more suggestions to the wiki. Two specific refactorings were covered that we believe need to have wiki-level discussion before proceeding: * What to do with signed comments. Flip around the sense of RefactorOk, so the wiki is "always" factorable unless otherwise noted. * Seperate Thread and Document mode. Begin seperating threads and document, making DocumentMode pages primary. In a mature wiki, one would not normally preserve the threads themselves, in our wiki, at this time, it may make more sense to hold on to them for a while. There were lots of ideas for factoring the FrontPage. The complete IRC log is included below. We decided to have twice weekly WikiGardening chats for a while, with the first two coming up next Tuesday and Thursday at the same time. See FrontPage for local timezones. Thanks to everyone who participated in the first WikiGardening chat! -- Ken MacLeod ---------- WikiGardening snapshot ---------- == Specific refactorings == (not prioritized) * FrontPage * restate first paragraph * bullet points should probably be severely pruned * separate intro pages for developers / visitors * polls * list of openpolls should probably be maintained manually to point to the most important ones. * Separating the Open Polls out of Current Focus, and into a section in its own right. * page needs to convey history, status, and goals, and it's not doing particularly well at any of that * provide a single naming status page and wiki-include it in all historical naming pages * identify, mark, or archive obsolete pages * replace arbitrary format names with an easy to replace tag pending final naming decision * make sure each page covers one topic * factor larger pages into smaller ones, or summarize * StatusReports should be status reports, milestones and current status elsewhere * RoadMap should link to related pages == Refactorings requiring notice, discussion, and/or vote == * What to do with signed comments * suggestion: flip around RefactorOk and make it NoRefactor * Separate Thread and Document mode * consolidate pages on similar/same topics == Organization == * Identify key target audiences and related information needs * list "hot" pages * look into FrontPage and SiteNavigation * first impression * organized collection of all topics * Announcements * reference implementations and examples, distinct from ["Tools"] * linking Wiki/IRC/mail discussions ---------- IRC Log ---------- --- bitsko has changed the topic to: Wiki Gardening Chat -- 15:30Z, 90 minutes -- http://intertwingly.net/wiki/pie/WikiGardening bitsko: okay. Is there an agenda, and is someone logging the discussion? yes, this chat will be logged and published. wow. people here. how do i say something off log? don't say it --> wob_ (~wobzilla@schluter.xs4all.nl) has joined #echo I will remove statements by request The agenda is as listed on the WikiGardening page: * prioritize specific refactorings * identify potential organizational techniques * perform more significant refactorings with reviewers available for immediate sanity checks * schedule future chats --> f8dy (~chatzilla@cpe-024-211-176-220.nc.rr.com) has joined #echo I propose starting with the front page. I will scribe and facilitate for the first two items, but I did not come with specific refactorings or organizations in mind, preferring others to throw out ideas first ok, "FrontPage". anything specific? Well, obviously no one reads the first paragraph, because it still says "argued over endlessly" so we should probably shorten it or get rid of it * bitsko notes he is making edits to WikiGardening and will announce refreshes. others should not be editing that page at this time and the rest of the bullet points should probably be severely pruned. the list of openpolls should probably be maintained manually to point to the most important ones