From owner-atom-protocol Wed Sep 8 08:54:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88FsNgT070870 for ; Wed, 8 Sep 2004 08:54:23 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88FsNmo070869 for atom-protocol-skb; Wed, 8 Sep 2004 08:54:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88FsMOj070850 for ; Wed, 8 Sep 2004 08:54:22 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 75so603266rnk for ; Wed, 08 Sep 2004 08:54:20 -0700 (PDT) Received: by 10.38.59.69 with SMTP id h69mr2813729rna; Wed, 08 Sep 2004 08:54:20 -0700 (PDT) Received: by 10.38.165.69 with HTTP; Wed, 8 Sep 2004 08:54:19 -0700 (PDT) Message-ID: <3f1451f5040908085467fb7821@mail.gmail.com> Date: Wed, 8 Sep 2004 11:54:19 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: atom-protocol@imc.org Subject: Welcome In-Reply-To: <3f1451f5040908085138aad36c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <3f1451f5040908085138aad36c@mail.gmail.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Welcome to [atom-protocol], This design team has been formed as a part of the atompub workgroup. The justification for forming such a group has been covered in PaceProtocolDesignTeam2[1] >From that Pace: "For this design team, we propose a mailing list open to anyone, whose only restriction is that the only initial topic for discussion is the needed actions for the Atom protocol. The protocol design team will propose to the WG ways of closing all open issues in the Atom protocol document. The document editors will revise the protocol document based on what they hear from the WG. " What that means is that the output of this team is a series of Paces, all of which need to be accepted by the whole WG, which means discussion on [atom-syntax]. As we all know, the volume on atom-syntax has drowned out much discussion on the Protocol aspect of atom, as a result the protocol has lagged. The hope is a seperate mailing list will speed up progress. Also note that we are just a design team of the atompub WG and as such are still bound by the charter[2]. That's just my way of saying let's not wander too far afield as we look to move the protocol forward. As a starting point for the discussion I would like to point everyone to the TypePad implementation of the Atom Publishing Protocol[3]. There is a large chunk of functionality there that we currently don't cover such as the UploadURI (which is covered by PaceSimpleResourcePosting) and Categories. We also need to consider which elements are mandatory versus optional, in particular look at the elements that are dropped from the SixApart implementation when posting to a Book list using an ISBN. In addition from our own charter we have the following functionality we must address: * multiple authors for a feed * multiple subjects or categories in a feed * user authentication * adding, editing, and deleting users * setting and getting user preferences * creating, getting and setting related resources such as comments, templates, etc. [1] http://www.intertwingly.net/wiki/pie/PaceProtocolDesignTeam2 [2] http://www.ietf.org/html.charters/atompub-charter.html [3] http://sixapart.com/developers/atom/typepad/ Thanks, -joe -- Joe Gregorio http://bitworking.org From owner-atom-protocol Wed Sep 8 13:38:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88Kc38V098003 for ; Wed, 8 Sep 2004 13:38:03 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88Kc35Y098002 for atom-protocol-skb; Wed, 8 Sep 2004 13:38:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@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.11/8.12.9) with ESMTP id i88Kc2KM097986 for ; Wed, 8 Sep 2004 13:38:02 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i88KbWud019472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Sep 2004 13:37:32 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C59C7-0001e9-Jh by authid for ; Wed, 08 Sep 2004 13:37:31 -0700 Date: Wed, 8 Sep 2004 13:37:31 -0700 From: Greg Stein To: atom-protocol@imc.org Subject: Re: Welcome Message-ID: <20040908203731.GA6232@google.com> References: <3f1451f5040908085138aad36c@mail.gmail.com> <3f1451f5040908085467fb7821@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3f1451f5040908085467fb7821@mail.gmail.com> X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 08, 2004 at 11:54:19AM -0400, Joe Gregorio wrote: >... > What that means is that the output of this team is a series > of Paces, all of which need to be accepted by the > whole WG, which means discussion on [atom-syntax]. >... > As a starting point for the discussion I would > like to point everyone to the TypePad > implementation of the Atom Publishing > Protocol[3]. There is a large chunk of functionality >... > Categories. We also need to consider > which elements are mandatory versus optional, >... > In addition from our own charter we have the > following functionality we must address: > > * multiple authors for a feed > * multiple subjects or categories in a feed > * user authentication > * adding, editing, and deleting users > * setting and getting user preferences > * creating, getting and setting related resources such as > comments, templates, etc. This is certainly a valid approach to begin discussion -- what is being done today is a good demonstration of "what is needed?" However, I'd like to propose a different path for tackling the problem. Something a bit more methodical: * identify and design the data model - what objects are represented? - what properties do they have? - what are the relationships? * identify the operations needed to operate on the data model * define the protocol around the above items I think the last step will just kind of "fall out" once we have the first two items. Once the operations and data is known, then it becomes relatively trivial to express that within different protocol models (REST, SOAP, etc). This approach also defers the question of protocol representation and allows us to concentrate on the fundamentals of what we're trying to do. Any thoughts on trying this approach? Cheers, -g From owner-atom-protocol Wed Sep 8 14:00:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88L0oPe000220 for ; Wed, 8 Sep 2004 14:00:50 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88L0oDa000219 for atom-protocol-skb; Wed, 8 Sep 2004 14:00:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from [165.227.249.219] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88L0lce000210; Wed, 8 Sep 2004 14:00:48 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20040908203731.GA6232@google.com> References: <3f1451f5040908085138aad36c@mail.gmail.com> <3f1451f5040908085467fb7821@mail.gmail.com> <20040908203731.GA6232@google.com> Date: Wed, 8 Sep 2004 14:00:51 -0700 To: Greg Stein , atom-protocol@imc.org From: Paul Hoffman / IMC Subject: Re: Welcome Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 1:37 PM -0700 9/8/04, Greg Stein wrote: >* identify and design the data model > - what objects are represented? > - what properties do they have? > - what are the relationships? > >* identify the operations needed to operate on the data model > >* define the protocol around the above items > >I think the last step will just kind of "fall out" once we have the first >two items. Once the operations and data is known, then it becomes >relatively trivial to express that within different protocol models (REST, >SOAP, etc). > >This approach also defers the question of protocol representation and >allows us to concentrate on the fundamentals of what we're trying to do. > >Any thoughts on trying this approach? Sounds good to me. People could be keeping side-notes on #3, but if the near-term focus the design is #1 and #2, we're much more likely to hit the actual needs of the users. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-protocol Wed Sep 8 16:26:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88NQpXf012975 for ; Wed, 8 Sep 2004 16:26:51 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88NQpxw012974 for atom-protocol-skb; Wed, 8 Sep 2004 16:26:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88NQo17012961; Wed, 8 Sep 2004 16:26:50 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.9]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C5BoW-0001pD-R5; Wed, 08 Sep 2004 23:25:20 +0000 Message-ID: <413F9534.90601@franklinmint.fm> Date: Wed, 08 Sep 2004 19:26:44 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: Greg Stein , atom-protocol@imc.org Subject: Protocol Data Model References: <3f1451f5040908085138aad36c@mail.gmail.com> <3f1451f5040908085467fb7821@mail.gmail.com> <20040908203731.GA6232@google.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > At 1:37 PM -0700 9/8/04, Greg Stein wrote: > >> * identify and design the data model >> - what objects are represented? >> - what properties do they have? >> - what are the relationships? >> >> * identify the operations needed to operate on the data model >> The wiki seems like a pretty good place to sketch in these two points. Tracking mailing list threads will get old fast. I've started http://www.intertwingly.net/wiki/pie/ProtocolDataModel with objects and properties gleaned from the WG charter. Add and restructure as you like, but let's keep the debate on-list. Robert Sayre From owner-atom-protocol Wed Sep 8 21:43:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i894hTVq037230 for ; Wed, 8 Sep 2004 21:43:29 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i894hTsq037229 for atom-protocol-skb; Wed, 8 Sep 2004 21:43:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i894hSLf037223 for ; Wed, 8 Sep 2004 21:43:28 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 86193 invoked by uid 17064); 9 Sep 2004 04:43:35 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.139.127]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 9 Sep 2004 04:43:35 -0000 In-Reply-To: <413F9534.90601@franklinmint.fm> References: <3f1451f5040908085138aad36c@mail.gmail.com> <3f1451f5040908085467fb7821@mail.gmail.com> <20040908203731.GA6232@google.com> <413F9534.90601@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Cc: Danny Ayers From: Henry Story Subject: Re: Protocol Data Model Date: Thu, 9 Sep 2004 06:43:28 +0200 To: atom-protocol@imc.org X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i894hSLf037224 Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The data model work has already been done. Check out Danny Ayer's Atom-OWL model [1] or my more experimental model [2] which I have even illustrated with a UML diagram. The OWL file [3] contain that information in a formal w3c supported, machine readable way. To interact with those models directly tools such as Protégé are available. On 9 Sep 2004, at 01:26, Robert Sayre wrote: > >> At 1:37 PM -0700 9/8/04, Greg Stein wrote: >>> * identify and design the data model >>> - what objects are represented? >>> - what properties do they have? >>> - what are the relationships? The OWL model specifies all the above. >>> >>> * identify the operations needed to operate on the data model >>> > > The wiki seems like a pretty good place to sketch in these two points. > Tracking mailing list threads will get old fast. > > I've started > > http://www.intertwingly.net/wiki/pie/ProtocolDataModel > > with objects and properties gleaned from the WG charter. Add and > restructure as you like, but let's keep the debate on-list. > > Robert Sayre Henry Story http://bblfish.net/ [1] http://semtext.org/atom/atom.html [2] http://bblfish.net/work/atom-owl/2004-08-12/blogexample.html [3] http://bblfish.net/work/atom-owl/2004-08-12/Atom.n3 or http://bblfish.net/work/atom-owl/2004-08-12/Atom.owl [4] http://protege.stanford.edu/ (download full installation) From owner-atom-protocol Thu Sep 9 03:26:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89AQvUV082233 for ; Thu, 9 Sep 2004 03:26:57 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i89AQvsH082232 for atom-protocol-skb; Thu, 9 Sep 2004 03:26:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89AQtXg082212 for ; Thu, 9 Sep 2004 03:26:56 -0700 (PDT) (envelope-from Janne.Jalkanen@nokia.com) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i89AQt111721 for ; Thu, 9 Sep 2004 13:26:55 +0300 (EET DST) X-Scanned: Thu, 9 Sep 2004 13:26:34 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i89AQYvO029831 for ; Thu, 9 Sep 2004 13:26:34 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00x9bWzv; Thu, 09 Sep 2004 13:26:32 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i89AQWS08970 for ; Thu, 9 Sep 2004 13:26:32 +0300 (EET DST) Received: from [172.21.60.114] ([172.21.60.114]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 9 Sep 2004 13:26:08 +0300 Message-ID: <41402FBF.2080306@nokia.com> Date: Thu, 09 Sep 2004 13:26:07 +0300 From: Janne Jalkanen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040619 X-Accept-Language: fi, en-us, en MIME-Version: 1.0 To: atom-protocol@imc.org Subject: Re: Welcome References: <3f1451f5040908085138aad36c@mail.gmail.com> <3f1451f5040908085467fb7821@mail.gmail.com> <20040908203731.GA6232@google.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Sep 2004 10:26:08.0251 (UTC) FILETIME=[6B772CB0:01C49657] Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 'ello all! > Sounds good to me. People could be keeping side-notes on #3, but if > the near-term focus the design is #1 and #2, we're much more likely to > hit the actual needs of the users. Um. One of the needs of the users is quick execution. :) http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=109&STORY=/www/story/09-08-2004/0002246056&EDATE= "TypePad's new mobile features and the web features of Nokia Lifeblog will be demonstrated at DEMOmobile, a gathering of mobile industry key players in La Jolla, CA. The blogging capability of Nokia Lifeblog is based on the open ATOM standard, and will be available early 2005." So there's interest in Atom. And from our side, the Atom protocol as it is currently defined, is rather close to actual needs already. The binary format, metadata, and the feed state management have been our headaches, but PaceSimpleResourcePosting, PaceExtendedResourcePosting and the current discussion in atom-syntax seem good in that regard. I think we have a good base in the current protocol to start with. It seems to work in real life :) /Janne From owner-atom-protocol Sat Sep 11 06:34:36 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BDYZDp003620 for ; Sat, 11 Sep 2004 06:34:36 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8BDYZWk003619 for atom-protocol-skb; Sat, 11 Sep 2004 06:34:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BDYZ53003610 for ; Sat, 11 Sep 2004 06:34:35 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf5ds.cable.mindspring.com ([24.215.149.188] helo=[192.168.1.100]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C681Q-0005b1-5r for atom-protocol@imc.org; Sat, 11 Sep 2004 13:34:32 +0000 Message-ID: <4142FEF1.3000006@franklinmint.fm> Date: Sat, 11 Sep 2004 09:34:41 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-protocol@imc.org Subject: ProtocolDataModel issues Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Note that this data model is distinct from that of an Atom feed. http://www.intertwingly.net/wiki/pie/ProtocolDataModel Access control-- Blogs need access control settings. Entries do as well. Think of a draft post as "-rw-r-----". Users-- Greg Stein suggested using Principals from the WebDAV ACL spec as our conceptual model. http://webdav.org/specs/rfc3744.html#principals Templates-- Greg Stein: "how do we describe which syntax the template is using?" Could we use MIME? Vendors could register their template languages under vnd. or prs. Robert Sayre From owner-atom-protocol Sat Sep 11 09:32:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BGWjk8013412 for ; Sat, 11 Sep 2004 09:32:45 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8BGWjea013411 for atom-protocol-skb; Sat, 11 Sep 2004 09:32:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BGWiLt013403 for ; Sat, 11 Sep 2004 09:32:44 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so69407rnb for ; Sat, 11 Sep 2004 09:32:42 -0700 (PDT) Received: by 10.38.8.74 with SMTP id 74mr431650rnh; Sat, 11 Sep 2004 09:32:42 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 11 Sep 2004 09:32:42 -0700 (PDT) Message-ID: <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> Date: Sat, 11 Sep 2004 18:32:42 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Robert Sayre Subject: Re: ProtocolDataModel issues Cc: atom-protocol@imc.org In-Reply-To: <4142FEF1.3000006@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4142FEF1.3000006@franklinmint.fm> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 11 Sep 2004 09:34:41 -0400, Robert Sayre wrote: > > Note that this data model is distinct from that of an Atom feed. Distinct, ok, but why different? Shouldn't the feed model act as a starting point? So we'd have constructs like Feed, Entry, Person and so on defined as in the format, with additions needed in the context of the protocol layered on top. > http://www.intertwingly.net/wiki/pie/ProtocolDataModel I'm also a little puzzled by, e.g. Post Page: "A formatted display of a single entry.". - the model part is the Entry, surely the presentation should be dealt with separately? > Access control-- > Blogs need access control settings. > Entries do as well. Think of a draft post as "-rw-r-----". > > Users-- > Greg Stein suggested using Principals from the WebDAV ACL spec as our > conceptual model. http://webdav.org/specs/rfc3744.html#principals Ok, on the to-read list, this certainly sounds worth considering... > Templates-- > Greg Stein: "how do we describe which syntax the template is using?" > Could we use MIME? Vendors could register their template languages under > vnd. or prs. Lost me. Could you please explain how the syntax of templates relates to the data model. Cheers, Danny. -- http://dannyayers.com From owner-atom-protocol Sat Sep 11 10:41:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BHffu4016833 for ; Sat, 11 Sep 2004 10:41:41 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8BHffNq016832 for atom-protocol-skb; Sat, 11 Sep 2004 10:41:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BHfeNT016826 for ; Sat, 11 Sep 2004 10:41:40 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf5ds.cable.mindspring.com ([24.215.149.188] helo=[192.168.1.100]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C6Bsa-0005SB-Tw; Sat, 11 Sep 2004 17:41:41 +0000 Message-ID: <414338E0.2020106@franklinmint.fm> Date: Sat, 11 Sep 2004 13:41:52 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: atom-protocol@imc.org Subject: Re: ProtocolDataModel issues References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> In-Reply-To: <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Danny Ayers wrote: > On Sat, 11 Sep 2004 09:34:41 -0400, Robert Sayre wrote: > >>Note that this data model is distinct from that of an Atom feed. > > > Distinct, ok, but why different? Shouldn't the feed model act as a > starting point? > Well, sure. I was responding to comments that this work was "already done." Think of this exercise as a model for the resources the server must make available. There's more than just Atom format stuff there. For example, there's the a lot of functionality that would typically go in an admin screen in MT, Wordpress, etc. Adding/Removing users, adding categories, stuff like that. Make sense? > >>http://www.intertwingly.net/wiki/pie/ProtocolDataModel > > > I'm also a little puzzled by, e.g. Post Page: "A formatted display of > a single entry.". - the model part is the Entry, surely the > presentation should be dealt with separately? > The HTML representations are objects the model could take into account. > >>Templates-- >>Greg Stein: "how do we describe which syntax the template is using?" >>Could we use MIME? Vendors could register their template languages under >>vnd. or prs. > > > Lost me. Could you please explain how the syntax of templates relates > to the data model. > The protocol must provide capabilities for modification of templates (see charter). One of the properties of a template is its syntax/language. One way of identifying the "language" of a template is to give it a MIME type. Robert Sayre From owner-atom-protocol Mon Sep 13 03:07:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DA7gBY089088 for ; Mon, 13 Sep 2004 03:07:42 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DA7ge1089087 for atom-protocol-skb; Mon, 13 Sep 2004 03:07:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DA7gli089077 for ; Mon, 13 Sep 2004 03:07:42 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so377647rnb for ; Mon, 13 Sep 2004 03:07:43 -0700 (PDT) Received: by 10.38.8.61 with SMTP id 61mr1410600rnh; Mon, 13 Sep 2004 03:07:42 -0700 (PDT) Received: by 10.38.179.32 with HTTP; Mon, 13 Sep 2004 03:07:42 -0700 (PDT) Message-ID: <1f2ed5cd040913030721e366e5@mail.gmail.com> Date: Mon, 13 Sep 2004 12:07:42 +0200 From: Danny Ayers Reply-To: Danny Ayers To: atom-protocol@imc.org Subject: Entry deletion and distributed systems Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: If someone posts an entry and then later retracts it a local system can handle this ok, but distributing the retraction may not be quite so straightforward. Maybe it is feasible to distribute the entry identifier tagged as 'withdrawn' or even 'expired', but I suspect it may not be sensible to make anything of that at a global level, as it could never be 100% reliable and the inclusion of such a system in the specs may lead to unrealistic expectations. In other words, I'd suggest that rather than having the logic: Post => EntryExists Post & PostRetraction => !EntryExists We use: Post => EntryExists Post & PostRetraction => EntryExists & PostRetraction (and that's all!) - it's up to the end-user application to deal with that as it sees fit. So generally (web-wide) entries will only expire by get old and slipping into obscurity, not through any explicit (un)assertion. I believe this is consistent with the monotonicity and open world assumptions the logicians favour for reasoning on the web. Whatever, it's maybe something worth bearing in mind during discussions of caching and passing big data aggregations around. Cheers, Danny. -- http://dannyayers.com From owner-atom-protocol Mon Sep 13 12:30:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DJU2uE057251 for ; Mon, 13 Sep 2004 12:30:02 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DJU2qA057250 for atom-protocol-skb; Mon, 13 Sep 2004 12:30:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@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.11/8.12.9) with ESMTP id i8DJU2La057175 for ; Mon, 13 Sep 2004 12:30:02 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.9) with ESMTP id i8DJTedM022934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Sep 2004 12:29:45 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C6wWB-0002ci-Nw by authid ; Mon, 13 Sep 2004 12:29:39 -0700 Date: Mon, 13 Sep 2004 12:29:39 -0700 From: Greg Stein To: Robert Sayre Cc: Danny Ayers , atom-protocol@imc.org Subject: Re: ProtocolDataModel issues Message-ID: <20040913192939.GA9997@google.com> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414338E0.2020106@franklinmint.fm> X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Sep 11, 2004 at 01:41:52PM -0400, Robert Sayre wrote: > Danny Ayers wrote: > >On Sat, 11 Sep 2004 09:34:41 -0400, Robert Sayre > >wrote: > > > >>Note that this data model is distinct from that of an Atom feed. > > > >Distinct, ok, but why different? Shouldn't the feed model act as a > >starting point? > > Well, sure. I was responding to comments that this work was "already > done." Think of this exercise as a model for the resources the server > must make available. There's more than just Atom format stuff there. For > example, there's the a lot of functionality that would typically go in > an admin screen in MT, Wordpress, etc. Adding/Removing users, adding > categories, stuff like that. Make sense? I think it makes sense. And I also think that we need to be careful to define some limits around what the spec will cover and then be able to say "go use some other standard to deal with the rest of the stuff." Personally, I'd like to see the resource types and properties defined for all the things we need to manipulate, then just defer to WebDAV to do that. And use its extensible property model for all the vendor-specific stuff that people want. > >>http://www.intertwingly.net/wiki/pie/ProtocolDataModel > > > >I'm also a little puzzled by, e.g. Post Page: "A formatted display of > >a single entry.". - the model part is the Entry, surely the > >presentation should be dealt with separately? > > The HTML representations are objects the model could take into account. A URL points to a resource. Every resource should have a listing in our data model. In this case, a post page is a typical item in a blog setup, so I think it is important to have in the model. There are also relationships that are defined between that page and others in a blog. The important part is that the system is not necessarily a pure MVC, and it may not be described that way. The model is implied by the rules of HTTP, and its notions of resources and methods on those resources. > >>Templates-- > >>Greg Stein: "how do we describe which syntax the template is using?" > >>Could we use MIME? Vendors could register their template languages under > >>vnd. or prs. Ah. That sounds good. > >Lost me. Could you please explain how the syntax of templates relates > >to the data model. > > The protocol must provide capabilities for modification of templates > (see charter). One of the properties of a template is its > syntax/language. One way of identifying the "language" of a template is > to give it a MIME type. There are a number of reasons why you may want to know the syntax of the template. Imagine you have Mother-Of-All-Blog-Tools and it knows how to author 10 different, common template syntaxes. How does it know which of those is in use? Thus, the need for a property. Cheers, -g From owner-atom-protocol Mon Sep 13 12:32:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DJW1JU057503 for ; Mon, 13 Sep 2004 12:32:01 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DJW1ZU057502 for atom-protocol-skb; Mon, 13 Sep 2004 12:32:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@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.11/8.12.9) with ESMTP id i8DJW1JK057484 for ; Mon, 13 Sep 2004 12:32:01 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.9) with ESMTP id i8DJW0j3023633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Sep 2004 12:32:00 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C6wYR-0002d0-Er by authid for ; Mon, 13 Sep 2004 12:31:59 -0700 Date: Mon, 13 Sep 2004 12:31:59 -0700 From: Greg Stein To: atom-protocol@imc.org Subject: Q: required extensions? Message-ID: <20040913193159.GB9997@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm confused about the "required extensions" under the Entries data type. That seems like an oxymoron to me. If it is required, then it is part of the definition, isn't it? And not an "extension". Robert: I think you put that in there. Can you elaborate a bit? Cheers, -g From owner-atom-protocol Mon Sep 13 12:52:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DJqU16059432 for ; Mon, 13 Sep 2004 12:52:30 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DJqUNk059431 for atom-protocol-skb; Mon, 13 Sep 2004 12:52:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DJqT7K059416 for ; Mon, 13 Sep 2004 12:52:29 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C6wsF-00030Z-Kz; Mon, 13 Sep 2004 19:52:27 +0000 Message-ID: <4145FA6F.8010606@franklinmint.fm> Date: Mon, 13 Sep 2004 15:52:15 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Stein CC: atom-protocol@imc.org Subject: Re: Q: required extensions? References: <20040913193159.GB9997@google.com> In-Reply-To: <20040913193159.GB9997@google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greg Stein wrote: > I'm confused about the "required extensions" under the Entries data type. > That seems like an oxymoron to me. If it is required, then it is part of > the definition, isn't it? And not an "extension". > > Robert: I think you put that in there. Can you elaborate a bit? I was thinking of an Entry resource that was part of something like a Typepad Typelist. For example, a server might require a Music Typelist[0] Entry to contain a http://sixapart.com/atom/song#:album element. Robert Sayre [0] http://sixapart.com/developers/atom/typepad/#Adding_a_Song_to_a_Music_TypeList From owner-atom-protocol Mon Sep 13 13:14:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DKEElD061486 for ; Mon, 13 Sep 2004 13:14:14 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DKEEQp061485 for atom-protocol-skb; Mon, 13 Sep 2004 13:14:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DKEEPn061476 for ; Mon, 13 Sep 2004 13:14:14 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id F25A147BF7; Mon, 13 Sep 2004 13:13:19 -0700 (PDT) In-Reply-To: <414338E0.2020106@franklinmint.fm> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> Content-Transfer-Encoding: 7bit Cc: Robert Sayre From: Ezra Cooper Subject: Re: ProtocolDataModel issues Date: Mon, 13 Sep 2004 13:14:44 -0700 To: atom-protocol@imc.org X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here are some kinds of resources that I'd be interested in modeling in Atom: * Non-entry resources (images, etc.) * Templates - template body - name - target filename * Authors (Principals) * Categories * Weblog-level configuration Can we agree on at least a few weblog-level configuration fields that would be useful to be treated by the protocol? Such as title, description, HTML URL, maybe timezone... At the very least, having a URL for the blog entity provides a convenient place to do the "introspection" that you wouldn't want to expose on the public web pages; it could include service.* links to all the other editable resources. In the case of templates, I assume we all need a body and a name--but there's a lot of variation in determining what templates get used for what target pages. +1 to using MIME types to label the template language. The WebDAV ACL model looks interesting. At first blush it seems cumbersome, but having a ready-to-go spec for that functionality is attractive. In regard to ProtocolDataModel, what is intended by the items "Index Page" and "Post Page"? Are the outward-facing blog pages meant to be treated by the protocol? What operations would they permit? On Sep 13, 2004, at 12:29 PM, Greg Stein wrote: >>> I'm also a little puzzled by, e.g. Post Page: "A formatted display >>> of >>> a single entry.". - the model part is the Entry, surely the >>> presentation should be dealt with separately? > > A URL points to a resource. Every resource should have a listing in our > data model. In this case, a post page is a typical item in a blog > setup, > so I think it is important to have in the model. There are also > relationships that are defined between that page and others in a blog. But what is a "Post Page"? How is it different from an Entry and what is it useful for within the model? Ezra From owner-atom-protocol Tue Sep 14 14:45:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ELjPFu019030 for ; Tue, 14 Sep 2004 14:45:25 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8ELjP7C019029 for atom-protocol-skb; Tue, 14 Sep 2004 14:45:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ELjPMR019022 for ; Tue, 14 Sep 2004 14:45:25 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C7L77-0007X6-Pf; Tue, 14 Sep 2004 21:45:25 +0000 Message-ID: <4147666B.6010501@franklinmint.fm> Date: Tue, 14 Sep 2004 17:45:15 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ezra Cooper CC: atom-protocol@imc.org Subject: Re: ProtocolDataModel issues References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> In-Reply-To: <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ezra Cooper wrote: > > Here are some kinds of resources that I'd be interested in modeling in > Atom: > > * Non-entry resources (images, etc.) PaceSimpleResoucePosting takes care of this, right? I guess the only remaining question is how a client locates them, or what resource has these non-entry resources as a many: property. > * Templates > - template body > - name > - target filename Could this be rephrased as - content - MIME type - title - URI > * Authors (Principals) > * Categories What properties does a category need? - name - URI http://www.novell.com/documentation/director4/docs/help/books/cmgWebDAVClient.html#1003177 Has an example of applying "category references" to resources. I'm not saying we have to use WebDAV to do this. There's a clearly a tension between Atom and WebDAV metadata containment models. [0,1,2] > * Weblog-level configuration > > Can we agree on at least a few weblog-level configuration fields that > would be useful to be treated by the protocol? Such as title, > description, HTML URL, maybe timezone... What constitutes Weblog-level? Is there a vague agreement here? Robert Sayre [0] http://www.goland.org/Tech/spe-whitehead.pdf [see "Containment Model"] [1] http://www.franklinmint.fm/blog/archives/000180.html [2] http://www.franklinmint.fm/blog/archives/000174.html From owner-atom-protocol Tue Sep 14 16:43:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ENhtuq028516 for ; Tue, 14 Sep 2004 16:43:55 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8ENht7j028515 for atom-protocol-skb; Tue, 14 Sep 2004 16:43:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ENhqKe028505 for ; Tue, 14 Sep 2004 16:43:54 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [69.17.92.244] (dsl017-092-244.sfo4.dsl.speakeasy.net [69.17.92.244]) by rongo.sixapart.com (Postfix) with ESMTP id BE88B47BF7 for ; Tue, 14 Sep 2004 16:42:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <4147666B.6010501@franklinmint.fm> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ezra Cooper Subject: Re: ProtocolDataModel issues Date: Tue, 14 Sep 2004 16:43:22 -0700 To: atom-protocol@imc.org X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 14, 2004, at 2:45 PM, Robert Sayre wrote: > Ezra Cooper wrote: >> Here are some kinds of resources that I'd be interested in modeling >> in Atom: >> * Non-entry resources (images, etc.) > > PaceSimpleResoucePosting takes care of this, right? I guess the only > remaining question is how a client locates them, or what resource has > these non-entry resources as a many: property. Yes, I think so. I don't see any need to model these as anything other than a generic web resource. >> * Templates >> - template body >> - name >> - target filename > > Could this be rephrased as > - content > - MIME type > - title > - URI Is "URI" the for the XML Atom resource, or for the public HTML file? I was groping for a way to determine the URLs of the public HTML files. We could certainly have a static URL field to be used for templates that only generate one HTML file. However, a common scenario is that where one template will generate many HTML files, at URLs determined by a given pattern. If we wanted to get fancy, we could make the "URI" field MIME-typed, like the content field, so that you could use a template language to specify the scheme of URLs generated by that template. Clients could treat it as a vanilla text box, or they could provide UI help for certain URL-template languages. >> * Authors (Principals) >> * Categories > > What properties does a category need? > - name > - URI Do we want to model categories as hierarchical or flat, or as DAGs? If flat, then hierarchical tools might have to write out long path names for their categories. Do we stop at having a single parent for each category, or can we allow several parents (giving rise to DAGs)? Looks like there are at least two or three possible models for categories. I favor a hierarchical model, possibly with a fallback for tools that don't want to deal with hierarchies. For the fallback, it might be enough just to make sure that each category has a unique human-readable name so that users can select a category without seeing the hierarchy. >> * Weblog-level configuration >> Can we agree on at least a few weblog-level configuration fields that >> would be useful to be treated by the protocol? Such as title, >> description, HTML URL, maybe timezone... > > What constitutes Weblog-level? Is there a vague agreement here? What constitutes a "weblog"? The question of a generation. Here I'm thinking of something that corresponds to a "feed" but the "feed" is the reader's-side view and this entity would be the publisher's-side view. A feed is something fed to you; this is more like cooking. Maybe this is the same as the PostURI; maybe when you GET the PostURI, you get this feed-level resource. To rephrase that, suppose the PostURI is really a "weblog resource" or an "editable feed resource." When you POST to that resource, you're posting a new entry into the feed. When you GET that resource, you get the feed-level metadata (or even the full feed). This resource would also be the place where feed configuration extensions could be made. This would also be a place to offer links for discoverability of the other "lists": like the list of available categories. Currently, in TypePad, to get a list of available categories, you GET a URL ending in "/t/atom/weblog/blog_id=/svc=categories". Rather than set a standard form for this URL, I'm proposing it be chosen by the server and listed in the uber-discoverability resource which can be GOT at the PostURI. I like the idea of hiding most of the discoverability links at this feed-level resource, as opposed to dragging them down the front street on the HTML page. As has been discussed before, in a system with multiple blogs per author, author X might not want to reveal that she authors blogs B and C in addition to A; but she wants her posting client to recognize this so that she can move amongst them with ease. A GET on the PostURI would be authenticated. Alternatively, instead of offer links to other lists, we could bundle all that data into the result you GET at the PostURI. Also at the feed level in the protocol: how about a link to the server's help pages? In various places in a posting client, you might need to refer to docs for, say, the server's template language. The client could display an icon that links to the help link provided by the server. This would be an optional element at the weblog/feed level. It feels wrong to call this *thing* a "feed" on the protocol side, since it is editable. I don't want to be weblog-specific, either. What can we call an editable feed? Can we distinguish it from a "feed" per se, which is the thing documented over at "Atom Format" [1]? Ezra [1] http://ietfreport.isoc.org/idref/draft-ietf-atompub-format/ From owner-atom-protocol Tue Sep 14 19:35:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8F2Z6A5039272 for ; Tue, 14 Sep 2004 19:35:06 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8F2Z5sO039270 for atom-protocol-skb; Tue, 14 Sep 2004 19:35:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8F2Z30b039252 for ; Tue, 14 Sep 2004 19:35:04 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf5ds.cable.mindspring.com ([24.215.149.188] helo=[192.168.1.100]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C7PdS-0003iI-61; Wed, 15 Sep 2004 02:35:06 +0000 Message-ID: <4147AA60.6030007@franklinmint.fm> Date: Tue, 14 Sep 2004 22:35:12 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ezra Cooper CC: atom-protocol@imc.org Subject: Template IO (was: ProtocolDataModel issues) References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ezra Cooper wrote: > > On Sep 14, 2004, at 2:45 PM, Robert Sayre wrote: > >> Ezra Cooper wrote: >> >>> * Templates >>> - template body >>> - name >>> - target filename >> >> >> Could this be rephrased as >> - content >> - MIME type >> - title >> - URI > > > Is "URI" the for the XML Atom resource, or for the public HTML file? > > I was groping for a way to determine the URLs of the public HTML files. > We could certainly have a static URL field to be used for templates that > only generate one HTML file. However, a common scenario is that where > one template will generate many HTML files, at URLs determined by a > given pattern. If we wanted to get fancy, we could make the "URI" field > MIME-typed, like the content field, so that you could use a template > language to specify the scheme of URLs generated by that template. > Clients could treat it as a vanilla text box, or they could provide UI > help for certain URL-template languages. Oh... this is much more involved than what I was thinking of. I had a SimpleResource in mind, with a title property and maybe some notion of templateness. The URI would be where you PUT the template to update it. Now I understand that "target filename" was supposed to be roughly analogous to the "output file" in Movable Type. For those not familiar with MT template configuration, here's a screenshot: http://franklinmint.fm/archives/images/mt_interface.jpg The output filename seems to be way a to say that resource/collection A is a view of resource/collection B (the view is probably limited in quantity, time frame, etc). so B --> template --> A or B --> [input set] --> template --> [output set] --> A So the question is whether the input and output selection can be specified in an interoperable manner. I'm pessimistic, but if the WG can come to consensus, great. In other words, I think "output file" is really part of MT's template format. In WebDAV terms, an extension property. My feeling is that by leaving this up to MIME, there's space for future standardization work on templating. Robert Sayre From owner-atom-protocol Wed Sep 15 08:15:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FFFYKp012086 for ; Wed, 15 Sep 2004 08:15:34 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FFFYcj012085 for atom-protocol-skb; Wed, 15 Sep 2004 08:15:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FFFXp3012077 for ; Wed, 15 Sep 2004 08:15:33 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C7bVJ-0003Pa-VN; Wed, 15 Sep 2004 15:15:30 +0000 Message-ID: <41485C91.3010103@franklinmint.fm> Date: Wed, 15 Sep 2004 11:15:29 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ezra Cooper CC: atom-protocol@imc.org Subject: Categories (was: ProtocolDataModel issues) References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ezra Cooper wrote: > > On Sep 14, 2004, at 2:45 PM, Robert Sayre wrote: > >> What properties does a category need? >> - name >> - URI > > > Do we want to model categories as hierarchical or flat, or as DAGs? If > flat, then hierarchical tools might have to write out long path names > for their categories. Do we stop at having a single parent for each > category, or can we allow several parents (giving rise to DAGs)? Looks > like there are at least two or three possible models for categories. > > I favor a hierarchical model, possibly with a fallback for tools that > don't want to deal with hierarchies. For the fallback, it might be > enough just to make sure that each category has a unique human-readable > name so that users can select a category without seeing the hierarchy. > I meant DAG (I missed a many:parent property). We have a similar problem to users/principals[0] in WebDAV ACL, which defines a DAV:group-membership property[1]. We could revise this to: Category - URI - many: memberOfURIs - many: memberURIs (can be entrys or categories) - name Are you in favor of restricting categories to a hierarchical model, or just concerned about a requirement? I was thinking servers could restrict the model as they wish. Robert Sayre [0] http://webdav.org/specs/rfc3744.html#principal.properties [1] http://webdav.org/specs/rfc3744.html#rfc.section.4.4 From owner-atom-protocol Wed Sep 15 09:22:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGMOoQ018009 for ; Wed, 15 Sep 2004 09:22:24 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FGMOrB018008 for atom-protocol-skb; Wed, 15 Sep 2004 09:22:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGMNUC018002 for ; Wed, 15 Sep 2004 09:22:24 -0700 (PDT) (envelope-from Janne.Jalkanen@nokia.com) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8FGMP110395 for ; Wed, 15 Sep 2004 19:22:25 +0300 (EET DST) X-Scanned: Wed, 15 Sep 2004 19:21:52 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i8FGLqJ2017707 for ; Wed, 15 Sep 2004 19:21:52 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00splv9q; Wed, 15 Sep 2004 19:21:49 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8FFjsY08026 for ; Wed, 15 Sep 2004 18:45:54 +0300 (EET DST) Received: from [172.21.60.114] ([172.21.60.114]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 15 Sep 2004 18:45:47 +0300 Message-ID: <414863AA.70107@nokia.com> Date: Wed, 15 Sep 2004 18:45:46 +0300 From: Janne Jalkanen User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: fi, en-us, en MIME-Version: 1.0 To: atom-protocol@imc.org Subject: Re: ProtocolDataModel issues References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Sep 2004 15:45:47.0465 (UTC) FILETIME=[11A57B90:01C49B3B] Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> PaceSimpleResoucePosting takes care of this, right? I guess the only >> remaining question is how a client locates them, or what resource has >> these non-entry resources as a many: property. > > Yes, I think so. I don't see any need to model these as anything other > than a generic web resource. Generic web resources *with metadata* :-) Actually, one thing I would like to work on is the PaceExtendedResourcePosting. >>> * Templates >> Hmm... Are templates possibly too platform-specific? > > I like the idea of hiding most of the discoverability links at this > feed-level resource, as opposed to dragging them down the front street > on the HTML page. As has been discussed before, in a system with > multiple blogs per author, author X might not want to reveal that she > authors blogs B and C in addition to A; but she wants her posting > client to recognize this so that she can move amongst them with ease. > A GET on the PostURI would be authenticated. +1 on the basic idea, +0.1 on the GET on PostURI... Sort of smells like overloading a function with a functionality that is not quite there. It smells of a hack :). Still, it does make sense on some metaphysical level. After all, it is a resource to POST things to... > Also at the feed level in the protocol: how about a link to the > server's help pages? In order to provide generic Wiki editing capabilities, it would be useful to have a guide to the WikiMarkup, yes :) So a resounding +1 to this one. /Janne From owner-atom-protocol Wed Sep 15 09:34:08 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGY8E4018993 for ; Wed, 15 Sep 2004 09:34:08 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FGY85D018992 for atom-protocol-skb; Wed, 15 Sep 2004 09:34:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGY69p018983 for ; Wed, 15 Sep 2004 09:34:06 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so1053977rnb for ; Wed, 15 Sep 2004 09:34:05 -0700 (PDT) Received: by 10.38.8.74 with SMTP id 74mr3251925rnh; Wed, 15 Sep 2004 09:34:05 -0700 (PDT) Received: by 10.38.179.32 with HTTP; Wed, 15 Sep 2004 09:34:05 -0700 (PDT) Message-ID: <1f2ed5cd040915093461edc110@mail.gmail.com> Date: Wed, 15 Sep 2004 18:34:05 +0200 From: Danny Ayers Reply-To: Danny Ayers To: mint@franklinmint.fm Subject: Re: Categories (was: ProtocolDataModel issues) Cc: Ezra Cooper , atom-protocol@imc.org In-Reply-To: <41485C91.3010103@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <41485C91.3010103@franklinmint.fm> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: First of all I'm not at all sure categories have a place in the protocol at all, or for that matter anywhere in core Atom. Categorization on the web is a hard problem with different solutions being more appropriate in some circumstances than others. Secondly, if categories are to be considered in scope, then please can we not mandate a hierarchical model. Trees are too restrictive to use directly for many kinds of categorization, and often you have to make up ugly hacks to work around them. I'm a big fan of DAGs, but I think even such a restriction is a step too far. I go along with the idea of the servers using whatever model they wish. Cheers, Danny. On Wed, 15 Sep 2004 11:15:29 -0400, Robert Sayre wrote: > > Ezra Cooper wrote: > > > > On Sep 14, 2004, at 2:45 PM, Robert Sayre wrote: > > > >> What properties does a category need? > >> - name > >> - URI > > > > > > Do we want to model categories as hierarchical or flat, or as DAGs? If > > flat, then hierarchical tools might have to write out long path names > > for their categories. Do we stop at having a single parent for each > > category, or can we allow several parents (giving rise to DAGs)? Looks > > like there are at least two or three possible models for categories. > > > > I favor a hierarchical model, possibly with a fallback for tools that > > don't want to deal with hierarchies. For the fallback, it might be > > enough just to make sure that each category has a unique human-readable > > name so that users can select a category without seeing the hierarchy. > > > > I meant DAG (I missed a many:parent property). We have a similar problem > to users/principals[0] in WebDAV ACL, which defines a > DAV:group-membership property[1]. We could revise this to: > > Category > - URI > - many: memberOfURIs > - many: memberURIs (can be entrys or categories) > - name > > Are you in favor of restricting categories to a hierarchical model, or > just concerned about a requirement? I was thinking servers could > restrict the model as they wish. > > Robert Sayre > > [0] http://webdav.org/specs/rfc3744.html#principal.properties > [1] http://webdav.org/specs/rfc3744.html#rfc.section.4.4 > > -- http://dannyayers.com From owner-atom-protocol Wed Sep 15 09:49:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGnXGV020519 for ; Wed, 15 Sep 2004 09:49:33 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FGnXMv020518 for atom-protocol-skb; Wed, 15 Sep 2004 09:49:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGnXKp020508 for ; Wed, 15 Sep 2004 09:49:33 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C7cyH-0002Wh-28; Wed, 15 Sep 2004 16:49:29 +0000 Message-ID: <4148729A.8070406@franklinmint.fm> Date: Wed, 15 Sep 2004 12:49:30 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Ezra Cooper , atom-protocol@imc.org Subject: Re: Categories References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <41485C91.3010103@franklinmint.fm> <1f2ed5cd040915093461edc110@mail.gmail.com> In-Reply-To: <1f2ed5cd040915093461edc110@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Danny Ayers wrote: > First of all I'm not at all sure categories have a place in the > protocol at all, or for that matter anywhere in core Atom. > Categorization on the web is a hard problem with different solutions > being more appropriate in some circumstances than others. I'm not too psyched about it either, but many tools and the MetaWeblogAPI support them. > I'm a big fan of DAGs, but I think > even such a restriction is a step too far. I go along with the idea of > the servers using whatever model they wish. Do you consider the following model too restrictive? I'm not sure we can be any looser. Category - URI - many: memberOfURIs - many: memberURIs (can be entries or categories) - name/title Robert Sayre From owner-atom-protocol Wed Sep 15 11:10:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIAbJ8027775 for ; Wed, 15 Sep 2004 11:10:37 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FIAb6h027774 for atom-protocol-skb; Wed, 15 Sep 2004 11:10:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIAafS027765 for ; Wed, 15 Sep 2004 11:10:37 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so253279rnk for ; Wed, 15 Sep 2004 11:10:34 -0700 (PDT) Received: by 10.38.70.19 with SMTP id s19mr1156875rna; Wed, 15 Sep 2004 11:10:33 -0700 (PDT) Received: by 10.38.99.80 with HTTP; Wed, 15 Sep 2004 11:10:33 -0700 (PDT) Message-ID: <3f1451f504091511101115c5df@mail.gmail.com> Date: Wed, 15 Sep 2004 14:10:33 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Ezra Cooper Subject: Re: ProtocolDataModel issues Cc: atom-protocol@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 14 Sep 2004 16:43:22 -0700, Ezra Cooper wrote: > Maybe this is the same as the PostURI; maybe when you GET the PostURI, > you get this feed-level resource. > To rephrase that, suppose the PostURI is really a "weblog resource" or > an "editable feed resource." When you POST to that resource, you're > posting a new entry into the feed. When you GET that resource, you get > the feed-level metadata (or even the full feed). This resource would > also be the place where feed configuration extensions could be made. > > This would also be a place to offer links for discoverability of the > other "lists": like the list of available categories. Currently, in > TypePad, to get a list of available categories, you GET a URL ending in > "/t/atom/weblog/blog_id=/svc=categories". Rather than set a > standard form for this URL, I'm proposing it be chosen by the server > and listed in the uber-discoverability resource which can be GOT at the > PostURI. > > I like the idea of hiding most of the discoverability links at this > feed-level resource, as opposed to dragging them down the front street > on the HTML page. I would offer the Introspection file as a good place to store all such links. The Introspection file was part of the protocol at one point, then dropped in the name of 'simplifying' the protocol. We should consider bringing it back. Note that the Introspection file had it's own URI that was seperate from the other protcol URIs. http://bitworking.org/projects/atom/draft-gregorio-05.html#rfc.section.4.1 http://bitworking.org/news/Extending_the_AtomAPI -joe -- Joe Gregorio http://bitworking.org From owner-atom-protocol Wed Sep 15 11:23:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FINgjN029152 for ; Wed, 15 Sep 2004 11:23:42 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FINgBc029151 for atom-protocol-skb; Wed, 15 Sep 2004 11:23:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@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.11/8.12.9) with ESMTP id i8FINf6Y029137 for ; Wed, 15 Sep 2004 11:23:41 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i8FINb0S008305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Sep 2004 11:23:37 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C7eRN-0006HC-9A by authid for ; Wed, 15 Sep 2004 11:23:37 -0700 Date: Wed, 15 Sep 2004 11:23:37 -0700 From: Greg Stein To: atom-protocol@imc.org Subject: Re: ProtocolDataModel issues Message-ID: <20040915182337.GC9997@google.com> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3f1451f504091511101115c5df@mail.gmail.com> X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 15, 2004 at 02:10:33PM -0400, Joe Gregorio wrote: >... > I would offer the Introspection file as a good place to > store all such links. The Introspection file was part of > the protocol at one point, then dropped in the > name of 'simplifying' the protocol. We should > consider bringing it back. How about we fall back to saying: what data do we need to represent? *Then* we talk about how to get it. You say "a new resource", and I say "WebDAV properties." But I'd rather defer that argument :-), and just figure out all the bits we're trying to represent on the server. Cheers, -g From owner-atom-protocol Wed Sep 15 11:31:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIVTwu029734 for ; Wed, 15 Sep 2004 11:31:29 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FIVT0h029733 for atom-protocol-skb; Wed, 15 Sep 2004 11:31:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIVTgg029722 for ; Wed, 15 Sep 2004 11:31:29 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id 1A11D47BF9 for ; Wed, 15 Sep 2004 11:30:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <3f1451f504091511101115c5df@mail.gmail.com> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <889A6050-0745-11D9-9EEA-000A95CFF6CC@sixapart.com> Content-Transfer-Encoding: 7bit From: Ezra Cooper Subject: Introspection Date: Wed, 15 Sep 2004 11:32:01 -0700 To: atom-protocol@imc.org X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 15, 2004, at 11:10 AM, Joe Gregorio wrote: > Note that the Introspection file had it's own URI that > was seperate from the other protcol URIs. Just curious, if it weren't for the history, what would be the advantage of separating the PostURI from the introspection URI? The "feed" is a resource; in one case we're posting to it, in another case we're getting information about it. Is it the distinction between "getting a representation of" and "getting data about"? Ezra From owner-atom-protocol Wed Sep 15 11:33:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIXQYa029916 for ; Wed, 15 Sep 2004 11:33:26 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FIXQT8029915 for atom-protocol-skb; Wed, 15 Sep 2004 11:33:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIXPFl029907 for ; Wed, 15 Sep 2004 11:33:25 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id 53C5647BF7 for ; Wed, 15 Sep 2004 11:32:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: atom-protocol@imc.org From: Ezra Cooper Subject: Re: Categories Date: Wed, 15 Sep 2004 11:33:57 -0700 X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 15, 2004, at 9:34 AM, Danny Ayers wrote: > First of all I'm not at all sure categories have a place in the > protocol at all, or for that matter anywhere in core Atom. Outside of entries/feeds, they seem like the next most important thing to get interoperation for. I only shy away from allowing multiple parents because it gets more complicated at that point. Do we select one parent as the "primary" parent, in order to provide a canonical path from root to leaf? Can we allow cycles as long as there is a simple path to the root? I do worry about modeling this too specifically and being too restrictive in the long run. If trees aren't general enough, then maybe the simple solution is not to give them structure in the core, but just to give entries a category element and let extensions worry about structure. In that case, I'm still interested in a discoverable list of categories, although certainly some tools won't want to provide that. On Sep 15, 2004, at 9:34 AM, Danny Ayers wrote: > Categorization on the web is a hard problem with different solutions > being more appropriate in some circumstances than others. Agreed; is there a loose element that we can provide that will allow different solutions to be applied via extensions? Can you give some idea how broadly we should be thinking? Ezra From owner-atom-protocol Wed Sep 15 11:38:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIcqE2030468 for ; Wed, 15 Sep 2004 11:38:52 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FIcqm3030467 for atom-protocol-skb; Wed, 15 Sep 2004 11:38:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@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.11/8.12.9) with ESMTP id i8FIcpXq030460 for ; Wed, 15 Sep 2004 11:38:51 -0700 (PDT) (envelope-from stevej@google.com) Received: from [172.24.68.136] (chopper.corp.google.com [172.24.68.136]) (authenticated bits=0) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i8FIcopn003557 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Sep 2004 11:38:50 -0700 In-Reply-To: <889A6050-0745-11D9-9EEA-000A95CFF6CC@sixapart.com> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <889A6050-0745-11D9-9EEA-000A95CFF6CC@sixapart.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7C93D8BC-0746-11D9-99F1-000A95B09B46@google.com> Content-Transfer-Encoding: 7bit Cc: atom-protocol@imc.org From: steve jenson Subject: Re: Introspection Date: Wed, 15 Sep 2004 11:38:50 -0700 To: Ezra Cooper X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 15, 2004, at 11:32 AM, Ezra Cooper wrote: > On Sep 15, 2004, at 11:10 AM, Joe Gregorio wrote: > >> Note that the Introspection file had it's own URI that >> was seperate from the other protcol URIs. > > Just curious, if it weren't for the history, what would be the > advantage of separating the PostURI from the introspection URI? The > "feed" is a resource; in one case we're posting to it, in another case > we're getting information about it. Is it the distinction between > "getting a representation of" and "getting data about"? Because we were not simply introspecting a Blog's capabilities but a User's capabilities. Sorry, I'm joining this conversation late (I just noticed this mailing list) so please let me know if this has already been covered as I don't see this thread in the archive listing. -steve From owner-atom-protocol Wed Sep 15 11:40:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIeB4K030577 for ; Wed, 15 Sep 2004 11:40:11 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FIeBtR030576 for atom-protocol-skb; Wed, 15 Sep 2004 11:40:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIeBsv030566 for ; Wed, 15 Sep 2004 11:40:11 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id D6FD647BF7 for ; Wed, 15 Sep 2004 11:39:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: atom-protocol@imc.org From: Ezra Cooper Subject: Fwd: Template IO Date: Wed, 15 Sep 2004 11:40:42 -0700 X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [forgot to include the list on this last night] On Sep 14, 2004, at 7:35 PM, Robert Sayre wrote: > The output filename seems to be way a to say that resource/collection > A is a view of resource/collection B (the view is probably limited in > quantity, time frame, etc). > > so B --> template --> A > > or > > B --> [input set] --> template --> [output set] --> A > > So the question is whether the input and output selection can be > specified in an interoperable manner. I'm pessimistic, but if the WG > can come to consensus, great. I'm not sure I understand your schematic there, but the element I had in mind would determine what URLs were controlled by the template. So I might write a template that draws single-post pages and I want that template to be used to draw the pages at urls like http://host.com/blog/.html. Or I might want it to appear at http://host.com/blog//.html. This field would determine that schema. I too doubt we could do it in a truly interoperable way. In MT we use most of the generality of the MT template language to determine how the URLs are constructed. I was simply imagining that it could be an arbitrary text field, tagged with a type--the same way the template "content" is not likely to interoperate but can be interpreted by its type. > In other words, I think "output file" is really part of MT's template > format. In WebDAV terms, an extension property. My feeling is that by > leaving this up to MIME, there's space for future standardization work > on templating. That's totally reasonable; it should be an extension if it's not widely useful. Ezra From owner-atom-protocol Wed Sep 15 11:53:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIrTgK031520 for ; Wed, 15 Sep 2004 11:53:29 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FIrTTG031519 for atom-protocol-skb; Wed, 15 Sep 2004 11:53:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIrTKH031508 for ; Wed, 15 Sep 2004 11:53:29 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id A5E4547BF7; Wed, 15 Sep 2004 11:52:26 -0700 (PDT) In-Reply-To: <7C93D8BC-0746-11D9-99F1-000A95B09B46@google.com> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <889A6050-0745-11D9-9EEA-000A95CFF6CC@sixapart.com> <7C93D8BC-0746-11D9-99F1-000A95B09B46@google.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/alternative; boundary=Apple-Mail-1-1003123771 Message-Id: <9B34897E-0748-11D9-9EEA-000A95CFF6CC@sixapart.com> Cc: atom-protocol@imc.org From: Ezra Cooper Subject: Re: Introspection Date: Wed, 15 Sep 2004 11:54:00 -0700 To: steve jenson X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-1-1003123771 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Sep 15, 2004, at 11:38 AM, steve jenson wrote: > On Sep 15, 2004, at 11:32 AM, Ezra Cooper wrote: >> >> Just curious, if it weren't for the history, what would be the >> advantage of separating the PostURI from the introspection URI? The >> "feed" is a resource; in one case we're posting to it, in another >> case we're getting information about it. Is it the distinction >> between "getting a representation of" and "getting data about"? > > Because we were not simply introspecting a Blog's capabilities but a > User's capabilities. > > Sorry, I'm joining this conversation late (I just noticed this mailing > list) so please let me know if this has already been covered as I > don't see this thread in the archive listing. Sorry, that's my fault: "Introspection" was "Re: ProtocolDataModel issues" I had proposed [1] changing PostURI to be the URI of a resource called the "editable feed." It would include all feed-level metadata, plus the introspection links to other services (category list, other "editable feeds" accessible to the same user, etc.). So, just floating the idea of allowing a GET to the PostURI, returning a document with useful data about the "feed" as a whole, and which is atom-authenticated and thus can include private data for the author. Ezra [1] http://www.imc.org/atom-protocol/mail-archive/msg00015.html --Apple-Mail-1-1003123771 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII On Sep 15, 2004, at 11:38 AM, steve jenson wrote: On Sep 15, 2004, at 11:32 AM, Ezra Cooper wrote: Just curious, if it weren't for the history, what would be the advantage of separating the PostURI from the introspection URI? The "feed" is a resource; in one case we're posting to it, in another case we're getting information about it. Is it the distinction between "getting a representation of" and "getting data about"? Because we were not simply introspecting a Blog's capabilities but a User's capabilities. Sorry, I'm joining this conversation late (I just noticed this mailing list) so please let me know if this has already been covered as I don't see this thread in the archive listing. Sorry, that's my fault: "Introspection" was "Re: ProtocolDataModel issues" I had proposed [1] changing PostURI to be the URI of a resource called the "editable feed." It would include all feed-level metadata, plus the introspection links to other services (category list, other "editable feeds" accessible to the same user, etc.).Helvetica So, just floating the idea of allowing a GET to the PostURI, returning a document with useful data about the "feed" as a whole, and which is atom-authenticated and thus can include private data for the author. Ezra [1] http://www.imc.org/atom-protocol/mail-archive/msg00015.html --Apple-Mail-1-1003123771-- From owner-atom-protocol Wed Sep 15 12:30:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJU3gQ034416 for ; Wed, 15 Sep 2004 12:30:03 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FJU3L0034414 for atom-protocol-skb; Wed, 15 Sep 2004 12:30:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJU28k034401 for ; Wed, 15 Sep 2004 12:30:02 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 40DE67C2E7; Wed, 15 Sep 2004 22:19:50 +0200 (CEST) Date: Wed, 15 Sep 2004 21:33:21 +0200 To: "Ezra Cooper" Subject: Re: Categories References: Cc: "Atom Protocol" From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004 11:33:57 -0700, Ezra Cooper wrote: > Outside of entries/feeds, they seem like the next most important thing > to get interoperation for. I agree. Especially if they were based on a standard categorization system that made sense outside the tiny world of a single weblog system. One such categorization system is the IPTC NewsCode system: > I only shy away from allowing multiple parents because it gets more > complicated at that point. Do we select one parent as the "primary" > parent, in order to provide a canonical path from root to leaf? Can we > allow cycles as long as there is a simple path to the root? I do worry > about modeling this too specifically and being too restrictive in the > long run. IPTC has a pretty good solution to this. All categories are given a unique number. «Sport» have the number '15000000'. All sub-categories of «sport» will start with '15XXXXXX', and each sub-category ending with '0' is possibly a parent category, e.g. «aero and aviation sport» which has the number '15001000'. All sub-categories of «aero and aviation sport» will start with '15001XXX'; e.g. «parachuting» which has the number '15001001'. This system is pretty intricate, but very well thought out. And it works. I've worked with for a while, and although the learning curve was a bit steep, using it now solves a lot of problems. No need to parse strings and do awkward string comparison. There exist a system, and it is easy to follow. The nice thing is that all categories in IPTC can, and are meant to, be combined. So, you can add '15001001', '15000012', '15000002' and '08003002' to your entry, which then means you're writing something about senior, celebrity, parachuting women. The implementation and syntax details aren't very interesting, but they could look like this: -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-protocol Wed Sep 15 12:36:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJah2S034905 for ; Wed, 15 Sep 2004 12:36:43 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FJahMX034904 for atom-protocol-skb; Wed, 15 Sep 2004 12:36:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJagfa034898 for ; Wed, 15 Sep 2004 12:36:42 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C7fa6-0000Ij-8p; Wed, 15 Sep 2004 19:36:42 +0000 Message-ID: <414899CA.3010405@franklinmint.fm> Date: Wed, 15 Sep 2004 15:36:42 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Ezra Cooper , Atom Protocol Subject: Re: Categories References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Asbjørn Ulsberg wrote: > > On Wed, 15 Sep 2004 11:33:57 -0700, Ezra Cooper wrote: > >> Outside of entries/feeds, they seem like the next most important >> thing to get interoperation for. > > > I agree. Especially if they were based on a standard categorization > system that made sense outside the tiny world of a single weblog > system. One such categorization system is the IPTC NewsCode system: > -1. So far we have avoided semantics like that. There is no precedent in weblog systems for that. Everyone makes their own tiny little world. If there's a need for coordination, a URI can be agreed upon. Robert Sayre From owner-atom-protocol Wed Sep 15 12:45:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJjv0S035761 for ; Wed, 15 Sep 2004 12:45:57 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FJjvqk035760 for atom-protocol-skb; Wed, 15 Sep 2004 12:45:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJjusf035752 for ; Wed, 15 Sep 2004 12:45:56 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so268115rnk for ; Wed, 15 Sep 2004 12:45:55 -0700 (PDT) Received: by 10.38.70.19 with SMTP id s19mr1238831rna; Wed, 15 Sep 2004 12:45:54 -0700 (PDT) Received: by 10.38.99.80 with HTTP; Wed, 15 Sep 2004 12:45:54 -0700 (PDT) Message-ID: <3f1451f504091512451341af68@mail.gmail.com> Date: Wed, 15 Sep 2004 15:45:54 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Greg Stein Subject: Re: ProtocolDataModel issues Cc: atom-protocol@imc.org In-Reply-To: <20040915182337.GC9997@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004 11:23:37 -0700, Greg Stein wrote: > > On Wed, Sep 15, 2004 at 02:10:33PM -0400, Joe Gregorio wrote: > >... > > I would offer the Introspection file as a good place to > > store all such links. The Introspection file was part of > > the protocol at one point, then dropped in the > > name of 'simplifying' the protocol. We should > > consider bringing it back. > > How about we fall back to saying: what data do we need to represent? > > *Then* we talk about how to get it. You say "a new resource", and I say > "WebDAV properties." But I'd rather defer that argument :-), and just > figure out all the bits we're trying to represent on the server. I'll give the 'data model' idea a little more time, but I honestly haven't seen a lot of traffic on this list and we might need to make the discussion a bit more concrete to get more participation. -joe -- Joe Gregorio http://bitworking.org From owner-atom-protocol Wed Sep 15 12:54:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJsZ98036879 for ; Wed, 15 Sep 2004 12:54:35 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FJsZUp036878 for atom-protocol-skb; Wed, 15 Sep 2004 12:54:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJsY5w036824 for ; Wed, 15 Sep 2004 12:54:35 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id AF3047C2E7; Wed, 15 Sep 2004 22:44:22 +0200 (CEST) Date: Wed, 15 Sep 2004 21:57:59 +0200 To: mint@franklinmint.fm Subject: Re: Categories Cc: "Atom Protocol" References: <414899CA.3010405@franklinmint.fm> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <414899CA.3010405@franklinmint.fm> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004 15:36:42 -0400, Robert Sayre wrote: >> I agree. Especially if they were based on a standard categorization >> system that made sense outside the tiny world of a single weblog >> system. One such categorization system is the IPTC NewsCode system: > > -1. So far we have avoided semantics like that. There is no precedent in > weblog systems for that. Why should weblog systems and their current practice set the standard for how Atom is going to be modeled, and thus, used? > Everyone makes their own tiny little world. If there's a need for > coordination, a URI can be agreed upon. Why can't we use IPTC? Why is it better to grow our own system? -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-protocol Wed Sep 15 14:30:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FLUUuX049343 for ; Wed, 15 Sep 2004 14:30:30 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FLUT4q049342 for atom-protocol-skb; Wed, 15 Sep 2004 14:30:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@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.11/8.12.9) with ESMTP id i8FLUTV3049329 for ; Wed, 15 Sep 2004 14:30:29 -0700 (PDT) (envelope-from stevej@google.com) Received: from [172.24.68.136] (chopper.corp.google.com [172.24.68.136]) (authenticated bits=0) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i8FLUDNI005451 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Sep 2004 14:30:13 -0700 In-Reply-To: <9B34897E-0748-11D9-9EEA-000A95CFF6CC@sixapart.com> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <889A6050-0745-11D9-9EEA-000A95CFF6CC@sixapart.com> <7C93D8BC-0746-11D9-99F1-000A95B09B46@google.com> <9B34897E-0748-11D9-9EEA-000A95CFF6CC@sixapart.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6DB1CFB8-075E-11D9-99F1-000A95B09B46@google.com> Content-Transfer-Encoding: 7bit Cc: atom-protocol@imc.org From: steve jenson Subject: Re: Introspection Date: Wed, 15 Sep 2004 14:30:13 -0700 To: Ezra Cooper X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 15, 2004, at 11:54 AM, Ezra Cooper wrote: > I had proposed [1] changing PostURI to be the URI of a resource called > the "editable feed." It would include all feed-level metadata, plus > the introspection links to other services (category list, other > "editable feeds" accessible to the same user, etc.). > > So, just floating the idea of allowing a GET to the PostURI, returning > a document with useful data about the "feed" as a whole, and which is > atom-authenticated and thus can include private data for the author. > > Ezra > > [1] http://www.imc.org/atom-protocol/mail-archive/msg00015.html Yeah, this is currently what Blogger does. our service.feed and service.post URIs are the same and the service.feed URI returns data that's not necessarily in your public feed. I don't see a need for those two URIs to be separate, either. The symmetry seemed clear. Having more private data in there would be even better. My comment was that there's room for a user-level Introspection file as well as blog level. -steve From owner-atom-protocol Wed Sep 15 15:49:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FMnL39055277 for ; Wed, 15 Sep 2004 15:49:21 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FMnLHM055276 for atom-protocol-skb; Wed, 15 Sep 2004 15:49:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FMnLrT055267 for ; Wed, 15 Sep 2004 15:49:21 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id 7319B47BF7; Wed, 15 Sep 2004 15:48:19 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <8F5133F0-0769-11D9-9EEA-000A95CFF6CC@sixapart.com> Cc: "Atom Protocol" From: Ezra Cooper Subject: Re: Categories Date: Wed, 15 Sep 2004 15:49:54 -0700 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8FMnLrT055271 Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 15, 2004, at 12:33 PM, Asbjørn Ulsberg wrote: > On Wed, 15 Sep 2004 11:33:57 -0700, Ezra Cooper > wrote: > >> Outside of entries/feeds, they seem like the next most important >> thing to get interoperation for. > > I agree. Especially if they were based on a standard categorization > system that made sense outside the tiny world of a single weblog > system. One such categorization system is the IPTC NewsCode system: > > I'm also opposed to standardizing on one universal set of categories. How could we agree on the one that suits everyone's needs? If you, as an author, want to refer to some external category system, I think that's your business. Perhaps an attribute would allow you to tag your entry's category as referring to a certain hierarchy? My model for categories is that authors determine their own categorization system, and that categories are pre-established and long-lived. This is different from "tags" in the del.icio.us/Flickr model, which can be created on the fly. As such, I'm in favor of having modeling categories in some very general way and allowing clients to GET and PUT them to manipulate a hierarchy that's local to the Atom server. Ezra From owner-atom-protocol Wed Sep 15 16:07:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FN76nA056997 for ; Wed, 15 Sep 2004 16:07:06 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FN76YB056996 for atom-protocol-skb; Wed, 15 Sep 2004 16:07:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FN75wc056990 for ; Wed, 15 Sep 2004 16:07:05 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.4]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C7irh-0001oU-JN; Wed, 15 Sep 2004 23:07:05 +0000 Message-ID: <4148CB25.8070209@franklinmint.fm> Date: Wed, 15 Sep 2004 19:07:17 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Gregorio CC: Greg Stein , atom-protocol@imc.org Subject: Re: ProtocolDataModel issues References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <3f1451f504091512451341af68@mail.gmail.com> In-Reply-To: <3f1451f504091512451341af68@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Joe Gregorio wrote: > On Wed, 15 Sep 2004 11:23:37 -0700, Greg Stein wrote: > >>How about we fall back to saying: what data do we need to represent? >> >>*Then* we talk about how to get it. You say "a new resource", and I say >>"WebDAV properties." But I'd rather defer that argument :-), and just >>figure out all the bits we're trying to represent on the server. > > > I'll give the 'data model' idea a little more time, but > I honestly haven't seen a lot of traffic on this list > and we might need to make the discussion a bit more > concrete to get more participation. What data is represented by the introspection file? Robert Sayre From owner-atom-protocol Wed Sep 15 16:44:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FNilkk059119 for ; Wed, 15 Sep 2004 16:44:47 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FNilvj059118 for atom-protocol-skb; Wed, 15 Sep 2004 16:44:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FNikhb059110 for ; Wed, 15 Sep 2004 16:44:46 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so31759rnl for ; Wed, 15 Sep 2004 16:44:43 -0700 (PDT) Received: by 10.38.74.77 with SMTP id w77mr1043705rna; Wed, 15 Sep 2004 16:44:43 -0700 (PDT) Received: by 10.38.99.80 with HTTP; Wed, 15 Sep 2004 16:44:43 -0700 (PDT) Message-ID: <3f1451f5040915164425052909@mail.gmail.com> Date: Wed, 15 Sep 2004 19:44:43 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: Categories Cc: Ezra Cooper , Atom Protocol In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8FNikhb059113 Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004 21:33:21 +0200, Asbjørn Ulsberg wrote: > > On Wed, 15 Sep 2004 11:33:57 -0700, Ezra Cooper wrote: > > > Outside of entries/feeds, they seem like the next most important thing > > to get interoperation for. > > I agree. Especially if they were based on a standard categorization system > that made sense outside the tiny world of a single weblog system. One such > categorization system is the IPTC NewsCode system: I believe we need to provide a 'spot' for categorization information to go, and we should make sure that certain popular categorization systems 'fit' in the spot we make, but I don't believe we should bless one such system as the one and only system to use with Atom. -joe -- Joe Gregorio http://bitworking.org From owner-atom-protocol Wed Sep 15 18:48:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G1mRs8074363 for ; Wed, 15 Sep 2004 18:48:27 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8G1mR26074362 for atom-protocol-skb; Wed, 15 Sep 2004 18:48:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G1mQHa074351 for ; Wed, 15 Sep 2004 18:48:26 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i8G1mW53012075 for ; Wed, 15 Sep 2004 19:48:32 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I44000PX2CVN5@edgemail1.Central.Sun.COM> for atom-protocol@imc.org; Wed, 15 Sep 2004 19:48:32 -0600 (MDT) Received: from [10.242.56.100] ([208.54.15.1]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I4400KTW2CU3Q@mail.sun.net> for atom-protocol@imc.org; Wed, 15 Sep 2004 19:48:31 -0600 (MDT) Date: Wed, 15 Sep 2004 18:48:29 -0700 From: Tim Bray Subject: Re: Categories In-reply-to: To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: Atom Protocol , Ezra Cooper Message-id: <81ED1FDD-0782-11D9-854B-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=ISO-8859-1; format=flowed References: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8G1mQHa074357 Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 15, 2004, at 12:33 PM, Asbjørn Ulsberg wrote: >> Outside of entries/feeds, they seem like the next most important >> thing to get interoperation for. > > I agree. Especially if they were based on a standard categorization > system that made sense outside the tiny world of a single weblog > system. One such categorization system is the IPTC NewsCode system: > > -1. Not just on this, on any Universal Taxonomy of Everything for Atom. -Tim From owner-atom-protocol Wed Sep 15 19:08:50 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G28oTj076284 for ; Wed, 15 Sep 2004 19:08:50 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8G28omT076283 for atom-protocol-skb; Wed, 15 Sep 2004 19:08:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G28nBa076274 for ; Wed, 15 Sep 2004 19:08:49 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i8G28t53018962 for ; Wed, 15 Sep 2004 20:08:55 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I44000QN3AUNZ@edgemail1.Central.Sun.COM> for atom-protocol@imc.org; Wed, 15 Sep 2004 20:08:55 -0600 (MDT) Received: from [10.242.56.100] ([208.54.15.1]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I4400KCF3AT3N@mail.sun.net> for atom-protocol@imc.org; Wed, 15 Sep 2004 20:08:54 -0600 (MDT) Date: Wed, 15 Sep 2004 19:08:53 -0700 From: Tim Bray Subject: Re: ProtocolDataModel issues In-reply-to: <20040915182337.GC9997@google.com> To: Greg Stein Cc: atom-protocol@imc.org Message-id: <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> Sender: owner-atom-protocol@mail.i