February 16, 2004
RSS vs. Atom Continues
You know you've struck a nerve in the community when your blog traffic spikes tremendously, Dave Winer chimes in with comments, and even quotes you on his blog, Scripting News.
Dave also posted a link to an Atom translator to RSS. So, here's my question: If, as its supporters are saying, Atom is the way to go for news feeds, why would one need to translate it back to RSS 2.0? The only answer that immediately came to my mind is that RSS is so much more prevalent currently. Following this line of reasoning, an Atom-only site would be missing out on distribution opportunities if it didn't provide an RSS feed. I noticed that several comments mentioned that Atom is a moving target. To me, this seems to be both its greatest weakness and strength, and as a result I have a better understanding of this hotly contested debate.
Again, I'm not choosing sides, but I understand Dave Winer's reasons for freezing RSS -- it's easier to implement a stationary target, especially if it's already working for the masses. On the other hand, what happens eventually when a new need comes along? As we've all seen, web technology doesn't stand still. Will RSS be sufficiently extensible and open to change as new needs pop up? I certainly don't have the answers, but I'm pretty good at asking some of the tough questions.
I do think that some form of news feeds is here to stay for awhile yet. A month after I launched this blog, I noticed that over 42% of the hits were by RSS readers. Since RSS feeds don't authenticate (at least not here), the net effect on end readership was something less than that. Nevertheless, it is practically relevant.
Both camps obviously recognize that news feeds add value and readership. In their latest versions, a number of popular news aggregators are now supporting both RSS and Atom. So other than Atom supporters stating that Atom is more "open source" and not frozen, what are the benefits to us bloggers? Why should we choose to implement Atom on our blogs right now, or perhaps later down the road? In other words, if we do it, will they come?
| Web Wizardry
Posted by Jeff Beard
jt, you seem to miss the point as much as Dave does.
I am not lobbying for Atom or against RSS.
I am arguing that freezing RSS in its current form is wrong.
There is a difference between what I am doing and what you think I am doing.
snp - out -
Haha... "This are USERS"... I'm sure there were others, but what was the point of my last errata again?? I ferget...;-)
"This are USERS who have IMPLEMENTED a solution, [some of them] many years ago. And their [sic: they're]"
This, clearly, demonstrates a few things:
1) The flaws in ANY standards design process currently in use, and specifically the Atom process.
1a) Input from "Mike" who is at foo@bar is considered.
1b) "Andrew - point taken. I rarely let lose any personal criticism via anonymous forums. On the other hand, I've witnessed Dave let loose in discussions like these so often that perhaps my own restraint is automatically lower, half expecting the temperature to rise; fully expecting to get no where in the discussion with Mr. Winer. Time has generally proven the latter as a more common outcome than not." "Point well-taken" then launches another personal attack... Hm.
1c) "Of course, you could extend RSS with namespaces to achieve the same functionality. But..." I think some folks should wake up and smell the coffee. There is always gonna be a "but" in a space as large as 600,000,000 connected together.
2) "As Jeremy Z and others have noted (and proven) -- it's a ridiculously simple matter for software developers to add in Atom support." This is the PROBLEM. It's easy to implement, and it's gonna be hail ta pay to maintain... But not only that, if the Atom syntax actually DOES innovate, then it will become a lot harder than it is now, when the funtionality is, afaik, almost if not entirely, identical.
3) The question has been asked what does Atom do that RSS can't, and that has never been answered very well.
4) The premise of Atom is to be THE ONE AND ONLY FORMAT, as stated on the wiki.
4a) How's that unification of RSS 1.0/RDF 1.0 coming along in the Atom group. (I have not followed discussion in past month, but if discussion in past year is any indication, not too far along.) So there are now THREE basic formats: RDF/RSS/Atom. Atom has a large contingent of RDF folks, so where's the roadmap for this phase of the "unification of all prior formats"?
5) "If you want to create the next version of HTTP, go to the IETF/W3C and join the HTTP WG. If you want to create the next version of XHTML, go to the W3C and join the WG." Please. But I do wonder what the ETA is of the IETF/Atom spec? It's being implemented NOW, and my understanding is that there is/will be different flavors of Atom implemented.
6) I've studied the Atom process enough to know that Dave Winer ATTEMPTED to designing Atom as a follow-on to RSS2, but he was frozen out of the discussion. Goes back to point 1.
7) The easiest way to design a follow-on to RSS 2.0, that delivers something other than a code-cleanup? Something that promotes end-user benefits, not just some minor benefits for the aggregator-coder?
Glad you asked, but it's not a simple question. Complicated questions DO have answers, but the Atom process has shown itself to be singularly ineffective, so far. It was supposed to merge previous efforts, and instead has created a third fork in the roadmap.
And I was dissed when I stated this before: "The whole reason for Atom is because RSS is somehow related to DW."
Btw, is email@example.com a real email address? Or is pb just a snot-nosed punk? Hard to tell.
I saw a long list too, Yahoo, CNN, Nokia, MicroSoft, National Weather Service, mailman listservs, governments around the world, etc, etc, yada, yada.
This are USERS who have IMPLEMENTED a solution, many years ago. And their being asked (well, actually FORCED) to scrap all that for a "completely new spec" DESIGNED to NOT BE backwards-compatible, from the git-go.
Bad decision, by flawed decision-making process, obviously.
Thanks Andrew. You are indeed a friend.
"HTTP was good enough, as was HTML, and there's certainly nothing wrong with RSS."
HTTP 1.0 was good enough, before HTTP 1.1. HTML 3 was good enough, before HTML 4 and before XHTML. RSS 0.91 was good enough before RSS 2.0. Who is to say that RSS 2.0 is so good and so clearly extensible that there can not and should not be a new version, profile, official howto, second edition, whatever?
Clearly and demonstrably there is a large number of producer and consumer developers who think (thought) there should be, or we wouldn't have a complete new spec to show for it.
If you want to create the next version of HTTP, go to the IETF/W3C and join the HTTP WG. If you want to create the next version of XHTML, go to the W3C and join the WG.
If one wants to create the next edition of RSS, I hear they can. Can what, precisely? I'd like to hear someone besides Dave Winer suggest what those steps might be. (Dave's already written on the subject, but I don't understand it. Something about anybody, anywhere, anytime can write the next version and everyone will somehow know it's the next version.)
Andrew - point taken. I rarely let lose any personal criticism via anonymous forums. On the other hand, I've witnessed Dave let loose in discussions like these so often that perhaps my own restraint is automatically lower, half expecting the temperature to rise; fully expecting to get no where in the discussion with Mr. Winer. Time has generally proven the latter as a more common outcome than not.
My opinions on the short comings of RSS (which I believe Dave Winer would fix...except...) are based on rational thought and observation / participation in the RSS tool/information market over a number of years.
My observation of Dave and conclusions have also been formed over quite a number of years. I'll apologize for stating them here, but not for having them.
I believe Dave Winer is making a significant error in judgement by not contemplating updating RSS to meet needs which exist today.
Flippant responses like *"It's so funny, people used to argue against RSS because it had too many core elements. Wasn't that long ago. Now you're arguing that it has too few. (D.W.)"* are what drive people to build improved solutions on their own.
I harp on about Author because its such a clear example of an aspect of RSS that could be improved.
Clearly an email address is an inappropriate piece of data to pass around RSS networks these days to identify an author. Email addresses change all the time in this spam-laden age. Who wants to be a victim of even more spam? People change jobs, universities and ISP's frequently. Names change less frequently than email addresses.
Authorship is core. Multiple authors is reality. Email addresses as an author-identifier is Bad.
Dave is a bright man - I'm sure he can see this; and perhaps even see a non intrusive way to revise RSS and fix some of its more universal short comings.
This on-going RSS battle, seemingly always n+=1 years old, reminds me of other "standards" and entrenched vendors which all but disappeared due to intransigence.
I think that end would be a shame for RSS and Dave personally - but a similar fate for RSS seems more likely than not at this point.
Time to move on!
Oh geez, I missed the fact that the comments are reverse-chronological and didn't see that the group had gotten past Mike's post down below. Well, I guess my comments stand anyway, but they may seem a little out of context. Sorry about that.
Mike, you raise some interesting points, but I'd appreciate it if you'd refrain from the personal attacks. It hurts everyone. It's a poor substitute for reasoned debate and really, really counter-productive. From the one or two times I've gotten into the fray, I can tell you that responding to attacks is incredibly stressful and draining. Attacking is effortless, defending is hard. Try this thought experiment. Think about what you wrote about Dave. Now imagine a co-worker confronting you, say, at the office, in front of all of your peers: "Your project is not well thought out because it can't do X" "You have a 'I didn't invent this so it can't be good" attitude'." "You're just getting around to Y - man, we've had this stuff for years." Whether or not that person has valid criticisms, you'd probably want them to lay off the personal stuff, present research to back up their claims, try to see things from your point of view and approach you personally before making a show in front of the group. Otherwise it's an attack, that you now have to defend or have everyone walk away believing the attacker. Now imagine those attacks appearing daily in dozens of places. Would you want to be subjected to this or to see any of your friends subjected to it? I don't. Dave's my friend and I don't like to see people treat him like this. Please, lay off the personal stuff and back up your claims.
Seth, in either case you're dependent on cooperation between developers. Even with defined core elements, there's nothing stopping someone from defining a namespace and using elements from the namespace instead of the equivalent core element.
It's so funny, people used to argue against RSS because it had too many core elements. Wasn't that long ago. Now you're arguing that it has too few. Damned if you do, damned if you don't.
My opinion: the action isn't in the format, it's in the application. I've been saying this for years.
I'm looking at the RSS 2.0 spec and the Atom 0.3 format side-by-side, as well as Sam Ruby's slides. An Atom feed can declare that an author has a name, a Web page, and multiple email address; the RSS "author" is just an email address. An Atom feed can contain a link to the "next N entries in this feed"; RSS does not. The RSS spec is ambiguous about whether or not markup is permitted within a title; Atom elements are text/plain by default, but you want markup, you can explicitly declare it. Atom has separate "summary" and "content" tags, so an aggregator can show either or both to its users; RSS only has "description", which many blogging tools use for the entire content of a post.
Of course, you could extend RSS with namespaces to achieve the same functionality. But suppose Developer X uses a namespace to create an RSS 2.0 extension that allows you to declare multiple authors. Developer Y, unaware of (or distainful of) X's work, writes another extension, using a different namespace, that allows both multiple authors and declares a URL for each author. Developer A writes an extension that attaches names and URLs to authors, as well as providing a "next N entries" link. Developer B writes an extension that handles the "next N entries" link and distinguishes the summary from the content. Etc., etc., etc. How are the people who write tools for publishing and subscribing to syndication feeds going to decide what to support?
Congrats Dave on the nomination.
Now when will there be an RSS 2.0 that supports multiple authors and the distinction between Content and an Abstract?
Jeremy, feel free to apply your same logic to the distinction between Abstract and Content, which RSS doesn't have, and should.
But forget that, we can distill the entire problem with RSS into one issue as an example, Authors, as we've been discussing.
RSS already has little things in it. It has, after all, Author now (singular and without pertinent information like... incredibly... the AUTHORS NAME) and as well contains such terribly useful information such as ManagingEditor and Webmaster for gosh sakes... yet RSS can't handle, out of the box, an extremely common requirement: multiple authors.
I'm not suggesting that every little* thing be added -- but authorship is a *BIG thing, perhaps the next *BIGGEST thing next to the content itself.
(Whoops, that paragraph should be: In the event that you wish to declare that a given post is authored by multiple authors, declare in your item an [authors] tag (namespace "http://www.invalid.mike/author-spec-1 "), which shall be a sequence of [author] elements, each containing as text the name of one of the authors.
I dislike comment fields that silently strip tags instead of replacing them with < et. al.
Mike, the right question is "Why does multiple authors have to be core"?
I hereby do declare the following spec for your Multiple Authors case:
In the event that you wish to declare that a given post is authored by multiple authors, declare in your item an tag (namespace "http://www.invalid.mike/author-spec-1 "), which shall be a list of elements, each containing as text the name of one of the authors.
In the standard RSS author tag, put the email address of the most relevant contact point for the message, or nothing at all since it is after listed as "optional". (Optionally, auto-generate an email address that will send an email to all the authors; if you control all the authors (i.e., they are in-house, you're not annotating people outside), your technical people ought to be able to set such a beast up for you.)
There. RSS 2.0 now supports multiple authors. You want to indicate type of authorship? Go to town, fix it up. You want to indicate it some other way, maybe with FOAF references? Go to town, fix it up. Why are you waiting?
You have to implement readers for it, of course, but you have to do the same for Atom anyhow, so there's no advantage now.
You say, "RSS is fine if its only to solve the problem of bloggers." But I say back to you, by adding the requirement that all RSS consumers must understand multiple authorship in order to call themselves RSS consumers, it is you who are reducing the usefulness of RSS in the general case. By keeping the core small, it's usefulness is maximized; it can be used for blogs, newspapers, academic papers, television shows, radio shows, things we haven't even imagined yet. Load it down with [byline], [newssource], [authors], [citations], [televisionchannel], [radiostation], [discjockey], [commercialminutes], [drm], [legalreference], [signaltype], and everything else and you lose, you do not gain. (And maybe you want to add whether a given author is a professor or a grad student, whereas somebody else is in the commercial world wants to annotate company source.)
Every single last one of those elements is a necessity for RSS in some domain, every bit as much as you are treating "multiple authors" as a necessity. The fact that they are not core is what allows RSS to go there.
You say "Why can't we just add this one little thing to the core spec?" And I say, "There are hundreds of things that people could say that have exactly the same value." Anything that can be removed from the core, should be.
(Yes, in my opinion there are things that could actually come out. I see this as an effect of this being RSS 2.0, the fact that historical reality does impact specs, and the fact that of course, I didn't write the spec, but it doesn't have to be perfect.)
Jeremy - how is attribution of multiple authors possibly not a "core" element?
Maybe, if your vision of the problem domain is just "individual bloggers", you would have a point.
But Tom, Jane, and Heidi in their Grade 9 group science project would beg to differ.
As would a team of scientists working on a paper.
As would a group of analysts putting out a research document.
As would two reporters collaborating on a story.
And that is just one ultra-simple example of where the RSS spec falls down in what should be a core area.
RSS is fine if its only to solve the problem of bloggers. If so, perhaps Dave would consider renaming it RSBS Really Simple Blogging Syndication.
And therein lies my entire point...
Have a nice evening.
Dave Winer wrote:
> Eventually you will need one aggregator to read the BBC and another
> to read Google News, and a third to read Blogger sites.
I respectfully yet strongly disagree. I think this is, indeed, a red herring.
As Jeremy Z and others have noted (and proven) -- it's a ridiculously simple matter for software developers to add in Atom support.
Just because Google and likely others down the line don't wish to support two feed formats doesn't mean that it's not a rather trivial matter for software developers to support whatever they want. This is not an either-or issue.
Indeed, yesterday, I saw a list of every software developer that is or is soon planning to integrate Atom support into their offerings. It was a pretty damn huge list, and I'm willing to bet that 99% of those people and companies aren't planning on abandoning RSS support next week, or even anytime in the near future.
Personally, I use the wonderful aggregator NewzCrawler for Windows. The sole developer of that software added in Atom support before I even knew what Atom is.
Will people have to update their software? Well, if they're using online aggregators, no, obviously, though if they're using software on their computers, yep. A minor inconvenience, and one that would be likely to happen for other reasons anyway, as software packages mature and are extended with new and useful features.
Once again, I say, this whole RSS vs. Atom war isn't something the non-geeks likely care about, ever WILL care about, or even should care about. I wish, Dave, you would quit spreading FUD about everything breaking and the sky falling and so on.
And for the record: I haven't worked on the RSS specs or Atom specs, and I'm not an employee of any blogging-related company nor do I claim to speak for any organization or company.
Perhaps, Dave, one of the principal reasons that you face any opposition at all is due to comments like your last one back to me.
When I said that I only took a few moments to REVIEW YOUR SPEC AGAINST ATOM, that doesn't mean that my opinions are any less valid, no matter how much you wish they were.
No, it simply means that anyone involved even on the periphery of this discussion can plainly see where holes in RSS exist.
Whether you agree with me or not is irrelevant to me. Across innumerable KM implementations I have had to wrestle with these very issues with many software vendors. As an aside, its rather incredible that many products fail to provide for multiple authorship when this is one of the first stumbling blocks users run into.
If basic attribution of authorship for content can't even be adequately provided, then the same "big co's" you fear so much will indeed step all over you and bring out something else.
My issue with RSS is that it is frozen.
I hate to be repetitive, but: The core is frozen, the extensions aren't.
You don't need Dave's approval for an extension. If it's useful, people will use it. If it's useful enough, then effectively everyone will use it. But nobody will have to use it in order to implement RSS. Sticking such extensions in the core spec is an actively bad idea.
Keeping it out of the core lets you experiment and develop your ideas before you commit it to a spec. Keeping it out of the core lets those who are interested in the extension use it, while those who are not... who are quite likely to be in the vast majority!... may ignore it but still usefully derive what information they can from the feed.
Eventually, when things settle down, maybe you'll get it into RSS 2.1... or maybe you'll find that all the functionality you need already exists, there's no need to impose it (and I mean "impose" quite literally) on anybody else, and it can continue being a seperate namespace, which you can control as you see fit because it is not connected to RSS itself. (In fact, you can even potentially use the namespace in other applications, because your extension will be orthogonal to RSS.)
The zeal to stuff everything into a centralized spec, that will have much inertia and certainly not be able to evolve your pet extension as quickly as your pet extension could if it were on its own, is beyond me. Why do you want to bind your special ideas about multiple authors on the rest of us by encoding it into a spec? (I can think of at least three or four distinct semantic meanings of "multiple authors"; are you so certain which is correct in an RSS context that you are ready to encode it into the spec, before experimenting with it?) Why do you want to bind your extension's rate of evolution to the evolution rate of the main spec, which of necessity must be slow?
The RSS model of extension-via-namespaces is superior in nearly every way I can think of to extension-via-spec-expansion. Why must every extension be put in the core itself? Nothing kills the usefulness of a spec faster then complexity that a given implementer or user does not perceive as useful to themselves. Why should RSS become a kitchen-sink spec, when the typical extension won't even be well-understood because nobody has used it yet?
Does atom provide tools for precendents management in the core?
"there's one choice if we're going to have one format, and it can't be Atom"
The whole reason for Atom is because RSS is somehow related to DW. Enough people with enough ability to make things happen determined this was not the situation that they wanted. Thus, Atom. So the correct statement is that "there's one choice if we're going to have one format, and it can't be RSS."
>>I only took a few minutes to compare them myself
I think, based on a lot of the critiques I've read, that you're far from the only one.
RSS is doing the job. It's so broadly deployed that the only thing Atom can do is to create yet another format for aggregator developers to worry about. Later, as the BigCo's ship aggregators, it will fall on content developers to support all their various flavors. Eventually you will need one aggregator to read the BBC and another to read Google News, and a third to read Blogger sites. The only way to avoid that is to coalesce, no matter how much it hurts, no matter how much you have to endure, the only way this market matters is if instead of things flying apart they come together. That means everyone has to swallow their pride and compromise. Anon asks the right question. HTTP was good enough, as was HTML, and there's certainly nothing wrong with RSS, clearly, because it works, demonstrably.
So basically there are some techies who have to overcome the disappointment that they don't run this, neither do I, basically there's one choice if we're going to have one format, and it can't be Atom. Think about it. A little bit more than a few minutes please.
Dave's pros and cons are on the mark.
Jeremey's comments about the core needing to be frozen, are likewise on the mark. However, my assertion that the core of RSS is too limited, forcing wide use of extensions for what should be in the core, remains.
Answer me this:
- do you, or anyone you know, frequently work on a complex document in teams? Bingo, namespace extension for RSS, since you can only have 1 author for an item. This is a common place real world scenario that RSS does not handle.
- do you, or anyone you know, want to know the NAME of the author of an item? RSS 2.0 does not give you this, only an email address. An email address which will not be static, of course, in this spam filled age.
- do you, or anyone you know, want to see only an ABSTRACT rather than the full content in a feed? Great you can use the Description element; but what if you want the full content?
As a publisher, perhaps you or I would want to publish both.
As a tool or solution implementer, I bet I would prefer that the Abstract of a document be compiled by the publisher, rather than me having to arbitrarily chunk off n-lines of the content when people publish long content items...
These are all simple things that, if addressed, would make RSS far more useful.
Its understandable that these elements were not in the original specs, given where this solution came from. All I am saying is that RSS, in its present form, is incomplete - and that some thought and some additions would make it far better.
It seems that those who control the RSS spec are unwilling to open up and consider change to the "core", even though - in many people's opinion - the core needs enhancing. So is it any wonder that Atom is getting some traction?
Custom namespaces should not be the answer for everything.
I deliberately focussed on multiple authors/name attributes and the description vs Abstract and Content issue as I think these are clear examples of what anyone who would sit down today - in a locked room apart from the Atom and RSS discussion, but with syndication and publishing experience - would put in a CORE spec. They are good ideas and basic building blocks for information management, and are precisely the sorts of things that many people wrestle with every day in the KM world.
Surely if an unemotional look at the two specs were done (I only took a few minutes to compare them myself), and a broader look at publishing needs in general were undertaken, even more questions would arise...
I would like all of the Atom proponents to answer a simple question: has HTTP been limited in its uses despite being simplistic?
RSS is frozen. The extensions are not.
The core needs to be frozen, or it isn't a "spec". I'm yet to see something that shouldn't/couldn't be implemented as a namespace on RSS.
Adding a namespaced element to RSS doesn't "lock out" anybody, any more then adding a namespaced attribute in XHTML does. Things the software doesn't understand must be ignored; that's a general principle of namespace-extensible-type XML. Your generic newsreader may not understand the "precedents" information, but it will still understand the rest of the feed; there's no way around the fact your special tag will have to be implemented, whether the base format is RSS or Atom or some custom binary format.
There's no reason Mike's KM app couldn't and shouldn't be done as a namespace. Why wait, start now. Maybe a pros and cons table would help.
Pro for RSS -- it's here now, ready to use.
Con for RSS -- the core can't be changed. (Although it can be extended through namespaces.)
Pro for Atom -- if you want a feature in the core, you might be able to get it (if you can convince the others).
Con for Atom -- it's not a fixed thing. What you deployed last year can't be read by aggregators that support Atom today. Extrapolate -- you'll probably keep having to move as Atom changes.
Now the tradeoff doesn't seem that good to me. For the sake of not having to put something in a namespace (such a small cost, after all) you have to wait and keep pedaling.
BTW, that has nothing to do with whether I or anyone else invented it.
Freezing RSS would make sense if it was better thought out. As it is, for many serious publishing needs, it is not complete enough.
Lets make this concrete by using an example from your own industry: Law. Lets use Precedent Management.
Even in the simplest possible implementation, a firm's precendent RSS "database" would want contain information on who contributed to the precendent, as well as an abstract of sorts.
You want to be able to include the entire precedent such that people can review/search/slice and dice as they need, but you definitely will want some sort of abstract to facilitate rapid location of information relevant to your need.
RSS 2.0 provides neither concept, out of the box. Sure you can extend it via a custom name space, and in the process, lock out other potential users of this information not to mention "off the shelf" tools which your underfunded legal IT group might prefer to use instead of writing their own.
Tie this discussion back to the two concepts I mentioned yesterday in comments:
... would make it possible a simple precendents system using only the core support in Atom. But not in RSS 2.0.
I'm not suggesting the Atom spec is a work of art or is enough/too much/just right. What I am saying is that RSS isn't enough. That much is perfectly clear to this long time "KM" and information management practioner with real world experience.
For example, should the atom Entry element have its own "lang" element? Perhaps Entries should be able to override the feed's lang state. I write CMS solutions that have to serve the translated content, in different languages, from the same URL, to consumers using different languages. Perhaps the right thing is a seperate feed for each language, but I can think of a number of applications where this would not be true, and that translated summary and content should be part of a multi-lingual feed.
The second issue, is who/what should drive a spec. Maybe its none of the current parties.
Dave - well, he puts blinders on, with his "I didn't invent this so it can't be good" attitude. Perhaps that's not a fault of his alone...
At any rate, any single person is going to have too narrow a focus. Dave, for example, is just getting around to ontologies and categories - man, we've had this stuff for years. In paper for gosh sakes.
Any one vendor should not be driving this. The information management market is way bigger than one blog vendor or one CMS vendor.
Mark and the gang I think have done some good work already, but I wonder if perhaps everything is too politicized. Proof, I guess, will be in the resulting pudding.
The need to translate is there because not all aggregators support Atom. I originally wrote that code to translate any RSS into strict RSS, because the aggregator I was using didn't show some feeds the way I wanted to see them.
Thanks for this very thoughtful post.
Imho, the solution lies in your hands. If you can find a few more people like yourself who are new to RSS and approach it with an open mind, you will figure it out, and I'm listening and looking forward to hearing what you come up with.