On 4/28/05, Roger B. <[EMAIL PROTECTED]> wrote:
> 
> > That's fine, but we're not here to tailor the format to your app.
> 
> Robert: Seriously, dude. C'mon.
> 

You're right, that was too snippy. 

> But you asked a question, and I answered it. Honestly,
> straightforwardly, and without an weasel-words. I did not ask anyone
> to tailor anything to anything. Try that silly crap with others if you
> must, but spare me.
 
> Again, I support a SHOULD on summary. Not just adding an empty
> element... allowing publishers to drop it entirely, as long as they're
> aware they're doing something that will have an impact on the primary
> functionality of feed-consuming applications.

Your argument is mostly consistent. I'll try to explain why SHOULD
will create problems that don't exist today. Let's take del.icio.us.
Sometimes, their entries have descriptions. Sometimes, they don't.
Your SHOULD allows competitors to turn off their feeds at any time,
and point to the spec as justification. Even worse, it could be "oh,
some of their entries are buggy, so we drop those." I doubt your
intent is anything nearly that malicious, and you might be right that
the feeds in question suck, but using a SHOULD to back up that action
is exactly what we want to avoid. It might even be possible to write a
naive parser that actually malfunctioned on such feeds.

Basically, if what you say is true, we don't need to enforce a summary
at all. It'll take care of itself, like email and even HTML eventually
did (it's possible to create an entire page in Flash, but not
particularly effective in the market). If these sorts of feeds are
legitimate for a certain style of application, a SHOULD is bound to
bring questions my way wondering "what does that SHOULD *really*
mean?". If that were to happen, the only ethical thing to do would be
to refer the question to Mark Nottingham. I've begun training an email
filter to forward questions to him ;)

That is not a problem worth creating in return for advocating the type
of feed we think is cool right now.

Robert Sayre

Reply via email to