People seem confused about RFC 2119.

If it helps, here is an example. But, be aware, it is JUST an example at this point. I'd like to be able to discuss it without people questioning each other's commercial viability, personal relevance to this process, or talking about things "caching fire" or the like, OK?

I'm also staying away from "atom:summary" for the the moment as there continues to be more heat than light in that particular conversation.

With that in mind, I suggest that the following are roughly equivalent:

    atom:title MAY be empty, but be aware that if it is empty, the
    recipient MAY chose to ignore the entire entry.

    atom:title SHOULD NOT be empty, lest the recipient choses to ignore
    the entire entry.

While the latter is slightly stronger, what is being conveyed in each case is "you are free to do this, but be aware that there are implications that you need to consider". This is not meant as a value judgment. And to illustrate this example, I offer the following for Firefox users:

  http://intertwingly.net/stories/2005/05/12/

Even with this example in mind, things are not cut and dry:

    We could decide as a group that titles MUST be present and not
    empty.  Even knowing that this means that somewhere that somebody
    will create a feed either ignoring this requirement.  And it might
    even work.  But when things break, it is clear who to blame.

    We could decide as a group that titles SHOULD be present and not
    empty.  This puts both parties on notice.  If you include it, more
    things work.  If you don't, many things will still work.
    Furthermore, people who parse feeds are put on notice that from
    time to time they will encounter entries with empty titles.

    We could decide as a group that titles are completely OPTIONAL.
    This is pretty much the reverse of the MUST case above.  If things
    break, it is the recipient who is to blame.

I claim that we are free to pick amongst all three of these alternatives. We would also shunt this issue off to a Best Current Practices document.

What's worse, there is no magic numbers to guide us in this decision. Examples of things you WON'T find: "if not including a title affects more than 17% of the user base" or a if this affects a tool produced by a company with a market cap of greater than 6.3 billion dollars".

It comes down to judgment. And on matters of judgment, reasonable people will disagree.

 - - -

So far, we seem to have consensus that atom:id MUST be present in atom:entries. People who intend to consume atom feeds have expressed this requirement pretty clearly, and as a group we seem inclined to satisfy this requirement.

So far, I don't recall anybody stepping forward and saying that feeds without atom:category elements will be less effective. Now that I have said that, I'm sure that somebody could come up with an example, but that would only prove my point that this is about judgment.

 - - -

We have RFC 2119. We have Paul on record saying that if this actually is the will of the working group, scenarios such as these are appropriate uses of the word SHOULD. Note: this is not Paul advocating any particular outcome, simply saying that that option is open to us.

With all this in mind, my suggestion is that we all calm down for a few days, and discussion things other than text elements. And when we do revisit this discussion early next week, lets not start with atom:summary, OK?

- Sam Ruby



Reply via email to