Re: On organization and abstraction
On Feb 4, 2005, at 9:10 AM, Robert Sayre wrote: My interest is in simplification, not abstraction. For example, the draft wastes a lot of text talking in the abstract about various constructs rather than simply defining one element for each of those constructs. Person, Date, and Text constructs all save space because they avoid repetitive requirements, and they match up nicely with the Relax NG. I'm pretty sure the group has agreed to drop Service constructs, and mnot has already moved atom:id into an element definition for -06. Right, and Brent Simmons, one of the major implementors, published a blog entry talking about how much, as a programmer, he liked the person and link and so on constructs. -Tim
Re: On organization and abstraction
Tim Bray wrote: On reflection, I am growing very negative on almost all of the Organization Paces, including FeedRecursive, PaceEntriesElement, PaceCollection. Here's why: they represent to increase the level of abstraction in Atom, and in my experience, when the goal is interoperability across the network, abstraction hurts. There's a diff of your feed in PaceEntriesElement. It's pushing it to claim one is more interoperable than the other. You just asked for examples 15 minutes ago, why don't you wait for them? The word feed has entered the vocabulary, even the non-geek vocabulary, and the notion that there are things (entries, stories, items, whatever) in feeds likewise. None of the feed formats out there use the term feed in their vocabularies. Any attempt to abstract away and generalize along the lines of well, a feed is really an entry or well, an entry is really a feed or really, they're all just web resources and collections is dangerously close to verging on Architecture Astronautics. OK, define Feed and Entry. We haven't done it yet. I think calling other designs astronautics is unjustified. HeadInEntry is astronautics in the worst way--just nest them. But hey that's just my opinion. Also, atom:content is architecture astronautics. Base64? Please. HTML in atom:copyright? architecture astronautics. Put another way, Adam Bosworth, likely one of the best computer programmers in the world, said every time I add abstraction to an interface I lose 90% of the audience. I would like Atom to be more like Visual Basic and less like Lisp. This is not a meaningful comparison to me. On the other hand, the notion that sometimes you have collections of feeds is easy to understand, easy to verbalize, and widely evidenced in practice (cf PubSub friends), if not perhaps widely seen outside of geekland. So I think I'm +1 on PaceAggregationDocument. (And I think if we adopted that we could certainly lose PaceHeadInEntry, right Bob?) I think you should wait for examples. Robert Sayre
Re: On organization and abstraction
Graham wrote: On 4 Feb 2005, at 2:37 am, Tim Bray wrote: On the other hand, the notion that sometimes you have collections of feeds is easy to understand, easy to verbalize, and widely evidenced in practice (cf PubSub friends), if not perhaps widely seen outside of geekland. So I think I'm +1 on PaceAggregationDocument. (And I think if we adopted that we could certainly lose PaceHeadInEntry, right Bob?) If you removed the ability to have entries within the feeds in aggregation documents, I'm in. PaceHeadInEntry covers a fundamentally different task. Why in the world should we define some other document format? OPML will do that just fine. Robert Sayre
Re: PaceAggregationDocument (was: On organization and abstraction)
On 4/2/05 2:06 PM, Graham [EMAIL PROTECTED] wrote: If you removed the ability to have entries within the feeds in aggregation documents, I'm in. PaceHeadInEntry covers a fundamentally different task. A collection of feeds would be something like a list of blogs about a certain topic? You get all the information you need in the feed-head, and supplying entries is fairly redundant. Essentially supplying recent entries from those feeds would be extra metadata about the feed. I think the purpose of PaceAggregationDocument is to provide a means to subscribe to an intermediary aggregator like pubsub, and thus receive entries. A collection of feeds for the purpose of a blog roll (ie. no entries) can be modelled in atom as it currently stands - each entry is descriptive about some resource, being a feed, and you'd just have a link rel=alternate / to the feed itself. e.
Re: On organization and abstraction
On Feb 3, 2005, at 7:06 PM, Graham wrote: On the other hand, the notion that sometimes you have collections of feeds is easy to understand, easy to verbalize, and widely evidenced in practice (cf PubSub friends), if not perhaps widely seen outside of geekland. So I think I'm +1 on PaceAggregationDocument. (And I think if we adopted that we could certainly lose PaceHeadInEntry, right Bob?) If you removed the ability to have entries within the feeds in aggregation documents, I'm in. PaceHeadInEntry covers a fundamentally different task. I'm claiming they do the same thing. Instead of feed headidf1/id/head entry headidf1/id/head ide1/id /entry entry headidf1/id/head ide2/id /entry entry headidf2/id/head ide3/id /entry /feed you'd have aggregation headidf1/id/head feedidf1/id entryide1/id/entry entryide2/id/entry /feed feedidf2/id entryide3/id/entry /feed /aggregation Which on the face of it seems like an improvement. -Tim
RE: On organization and abstraction
Tim Bray wrote: So I think I'm +1 on PaceAggregationDocument. (And I think if we adopted that we could certainly lose PaceHeadInEntry, right Bob?) -1... PaceAggregationDocument does not seem to me to add much benefit for all the costs that it entails. I'm particularly concerned that adding a new type of root document aggregation is likely to add enough to the complexity of Atom that only a subset of developers will actually get around to supporting this third type of document -- a type which doesn't exist in the simple RSS aggregators that exist today. I see two non-compelling benefits to PaceAggregationDocument over PaceHeadInEntry: 1. In the case where a feed will contain more than one entry from a foreign feed, you only have to include the atom:head data once. Thus, there would be some increase in efficiency of encoding... However, as I've pointed out on numerous occasions, this is a rare case. Typically, at PubSub, we DO NOT see many cases where atom:head information is repeated in a single instance of a feed. 2. It is easier to see how one would sign an aggregated entry since you don't muck with the contents of entry by inserting the HeadInEntry. This problem, however, would be solved by canonicalization rules that said that you should remove HeadInEntry before processing signatures, or, rules that said that you had to insert HeadInEntry before signing anything, or filter rules that allowed one to flag HeadInEntry as not part of the signed content. (i.e. alternative solutions exist...) But, there are tremendous problems with the proposal: 1. It looks like I can't intersperse native entries with aggregated entries. This is a nuisance. I would like to see people insert entries with HeadInEntry when they copy something from another feed into their own feed. PaceAggregationDocument says that your feed must have either native entries or foreign entries, but it can't have both. This seems like an unnecessary constraint. 2. As mentioned before, the introduction of a new level of abstraction (i.e. aggregation) is likely to scare off a good proportion of the aggregator developers. Current aggregators don't have the concept of aggregation in them. Thus, new design and new architecture will be required to address this Pace. On the other hand, staying with HeadInEntry is much more gentle on the existing systems and thus much more likely to be useful in the field. 3. Since there will be at least some subset of aggregators that won't understand the aggregation thing, it is likely that we'll have a chicken and egg problem. No one will produce aggregation documents since not everyone supports them. Thus, no one will support them since no one generates them. On the other hand, HeadInEntry will slide past minimally updated aggregators with no trouble -- i.e. folk who don't want to do the work of handling the stuff properly will simply ignore the Head element... (i.e. it would be suicide for producers like PubSub to support PaceAggregationDocument.) 4. Massive changes need to be made to the specification when we don't have a great deal of time left before we're supposed to be doing a Last Call. This is dangerous. -1. I really don't see any compelling benefit in exchange for the tremendous risk and cost of accepting PaceAggregationDocument and dropping HeadInEntry. Let's avoid adding to the levels of abstraction here and keep it simple. We should have feeds and entries -- nothing else. I would like Atom to be more like Visual Basic and less like Lisp. As an ex-Visual Basic Product Manager, I think this would be a good idea! Let's keep it simple and NOT accept PaceAggregationDocument. (Note to reader: Visual Basic .NET is .NOT Visual Basic... bob wyman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Bray Sent: Thursday, February 03, 2005 9:38 PM To: Atom Syntax Subject: On organization and abstraction On reflection, I am growing very negative on almost all of the Organization Paces, including FeedRecursive, PaceEntriesElement, PaceCollection. Here's why: they represent to increase the level of abstraction in Atom, and in my experience, when the goal is interoperability across the network, abstraction hurts. I would like it if the markup found in Atom documents was as close as possible to a typical human mental model. The word feed has entered the vocabulary, even the non-geek vocabulary, and the notion that there are things (entries, stories, items, whatever) in feeds likewise. Any attempt to abstract away and generalize along the lines of well, a feed is really an entry or well, an entry is really a feed or really, they're all just web resources and collections is dangerously close to verging on Architecture Astronautics. Put another way, Adam Bosworth, likely one of the best computer programmers in the world, said every time
Re: On organization and abstraction
+1 - someone else made a comment about OPML which really hit the spot; if you try to make a format do all things, it does most of them badly... On Feb 3, 2005, at 6:37 PM, Tim Bray wrote: On reflection, I am growing very negative on almost all of the Organization Paces, including FeedRecursive, PaceEntriesElement, PaceCollection. Here's why: they represent to increase the level of abstraction in Atom, and in my experience, when the goal is interoperability across the network, abstraction hurts. I would like it if the markup found in Atom documents was as close as possible to a typical human mental model. The word feed has entered the vocabulary, even the non-geek vocabulary, and the notion that there are things (entries, stories, items, whatever) in feeds likewise. -- Mark Nottingham http://www.mnot.net/
Re: On organization and abstraction
On Thu, 3 Feb 2005 23:08:43 -0500, Bob Wyman [EMAIL PROTECTED] wrote: Tim Bray wrote: So I think I'm +1 on PaceAggregationDocument. (And I think if we adopted that we could certainly lose PaceHeadInEntry, right Bob?) -1... PaceAggregationDocument does not seem to me to add much benefit for all the costs that it entails. I'm particularly concerned that adding a new type of root document aggregation is likely to add enough to the complexity of Atom that only a subset of developers will actually get around to supporting this third type of document -- a type which doesn't exist in the simple RSS aggregators that exist today. +1 to this -1. The aggregation element is not a necessary part of the core and adds complexity without adding *significant* benefit to the core. 2. As mentioned before, the introduction of a new level of abstraction (i.e. aggregation) is likely to scare off a good proportion of the aggregator developers. Current aggregators don't have the concept of aggregation in them. Thus, new design and new architecture will be required to address this Pace. On the other hand, staying with HeadInEntry is much more gentle on the existing systems and thus much more likely to be useful in the field. This is precisely why I don't think this belongs in the core. For those who need this type of functionality, the opportunity exists for them to create a separate Internet-Draft that describes how to aggregate feeds -- without adding complexity to the core syntax by introducing elements that the vast majority of users will *likely* never use. (I obviously base this assumption on the reasoning that most Atom users will use it as a drop in replacement for RSS). 3. Since there will be at least some subset of aggregators that won't understand the aggregation thing, it is likely that we'll have a chicken and egg problem. No one will produce aggregation documents since not everyone supports them. Thus, no one will support them since no one generates them. Well, I wouldn't go this far. There is obviously a requirement for it for some folks and those folks are likely to make good use of it. What I would rather see the WG do is take a minimalist approach with this. Right now, I see aggregated feeds falling into that limited 20% of use cases that could be done, but aren't necessarily critical to be done. Aggregation could be defined as an extension to Atom, and later, based on an analysis of its implementation over time, can be merged into the Atom core if deemed appropriate. Merging it into the core now does not guarantee that its adoption and use will be any greater than if it were done as an extension. 4. Massive changes need to be made to the specification when we don't have a great deal of time left before we're supposed to be doing a Last Call. This is dangerous. +1. Big +1. -1. I really don't see any compelling benefit in exchange for the tremendous risk and cost of accepting PaceAggregationDocument and dropping HeadInEntry. Let's avoid adding to the levels of abstraction here and keep it simple. We should have feeds and entries -- nothing else. One point, HeadInEntry solves the problem of having a standalone Atom Entry document be able to reference a feed of which it is a part. Unless I'm misreading something, if PaceAggregationDocument gets rid of the ability to put Head elements in the entry, don't we lose this capability? (this is something that is important, for instance, in my Atom Notification Protocol proposal) I would like Atom to be more like Visual Basic and less like Lisp. As an ex-Visual Basic Product Manager, I think this would be a good idea! Let's keep it simple and NOT accept PaceAggregationDocument. (Note to reader: Visual Basic .NET is .NOT Visual Basic... Aargh! VB... it burns! (sorry, temporary flashback to past hell. Sorry Bob, VB was an excellent product, I just was forced to be witness to some extremely bad uses of it. Nightmares, I tell you, nightmares!) bob wyman -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
Re: On organization and abstraction
James Snell wrote: On Thu, 3 Feb 2005 23:08:43 -0500, Bob Wyman [EMAIL PROTECTED] wrote: 4. Massive changes need to be made to the specification when we don't have a great deal of time left before we're supposed to be doing a Last Call. This is dangerous. +1. Big +1. I really regret writing down the religion that format-05 seems to embody. Take a look at PaceEntriesElement. It does not propose a massive change. It's just *shorter*. Some quotes from format-05: Atom is an XML-based document format which describes lists of related information known as feeds. Feeds are composed of a number of items, known as entries, each with an extensible set of attached metadata. For example, each entry has a title. The atom:feed element is the document (i.e., top-level) element of an Atom Feed Document, acting as a container for metadata and data associated with the feed The atom:entry element represents an individual entry. I really must find out more about this theology that allows one to divine the precise nature of lists, data, metadata, items, containers, and representations. Robert Sayre
Re: On organization and abstraction
On Thursday, February 3, 2005, at 09:08 PM, Bob Wyman wrote: I see two non-compelling benefits to PaceAggregationDocument over PaceHeadInEntry: 1. In the case where a feed will contain more than one entry from a foreign feed, you only have to include the atom:head data once. Thus, there would be some increase in efficiency of encoding... However, as I've pointed out on numerous occasions, this is a rare case. Typically, at PubSub, we DO NOT see many cases where atom:head information is repeated in a single instance of a feed. In the past few days, I've been reading people talking about different ways emerging for people to combine or divide the content of their own feeds based on what's going to end up in our category element and by other methods. (See http://www.mezzoblue.com/archives/2005/02/03/information_/index.php). This kind of thinking could very well point the way to the emergence of more feeds being aggregated from a small number of sources. Time will tell. 2. It is easier to see how one would sign an aggregated entry since you don't muck with the contents of entry by inserting the HeadInEntry. This problem, however, would be solved by canonicalization rules that said that you should remove HeadInEntry before processing signatures, or, rules that said that you had to insert HeadInEntry before signing anything, or filter rules that allowed one to flag HeadInEntry as not part of the signed content. (i.e. alternative solutions exist...) When you remove HeadInEntry, do you remove from the start of the head tag to the end of the /head tag, or do you also take out the newline after the /head tag...? We'd have to be certain we defined the process precisely and that people followed it precisely. The benefit of avoiding that complexity may be a little greater than it appears at first blush. But, there are tremendous problems with the proposal: 1. It looks like I can't intersperse native entries with aggregated entries. This is a nuisance. I would like to see people insert entries with HeadInEntry when they copy something from another feed into their own feed. PaceAggregationDocument says that your feed must have either native entries or foreign entries, but it can't have both. This seems like an unnecessary constraint. You could always have a feed in the aggregation for the native entries. But you do have a point--the thing that would be more difficult would be to occasionally import external content into a feed that is not always an aggregation--you'd either have to temporarily become an aggregation, refer to it rather than importing it, or forget it. Out of curiosity though, how common is it to import entries wholesale from external sources as opposed to referring to them? 2. As mentioned before, the introduction of a new level of abstraction (i.e. aggregation) is likely to scare off a good proportion of the aggregator developers. Current aggregators don't have the concept of aggregation in them. Thus, new design and new architecture will be required to address this Pace. On the other hand, staying with HeadInEntry is much more gentle on the existing systems and thus much more likely to be useful in the field. Current aggregators don't have the concept of HeadInEntry either. With HeadInEntry, it's easier because you don't have to deal with one more level of hierarchy--if you don't know about HeadInEntry and just ignore it, you can still function. However, that leads to erroneously attributing an entry to the wrong feed. To get it right, aggregators are going to have to understand SOMETHING new. The containment in an aggregation document would be more intuitively obvious in meaning than seeing a head in an entry and figuring out that it was the head from the feed that used to surround the entry. 4. Massive changes need to be made to the specification when we don't have a great deal of time left before we're supposed to be doing a Last Call. This is dangerous. If we don't want to reorganize the spec to do this, we can create PaceAggregationDocument2 which does it more simply by making only four changes: 1) add an aggregation element 2) state that it requires an atom:head 3) state that it can contain any number of atom:feeds 4) state that it can be the document element
