Subject: PaceTextShouldBeProvided

From: Sam Ruby <[email-masked]>
Date: Fri, 29 Apr 2005 12:51:24 -0400

== Abstract ==

Encourage interoperability and accessibility by suggesting that key 
textual constructs be both present and non-empty.

== Status ==

Open

== Rationale ==

There are existance proofs of tools that either are less useful in the 
presence of entries without without a title, or ones without either a 
summary or inline textual content.  In fact, at least one such tool 
discards such entries entirely.  This fact, when viewed in isolation, 
would argue that such elements be mandatory.

Unfortunately, there are also existence proofs of title-only feeds, and 
entries for which there are no titles.  Reluctantly, this leads one to 
conclude that while they must be allowed, it would be irresponsible for 
the spec not to warn potential producers of such feeds that not 
providing a textual fallback may lead to interoperability issues.

== Proposal ==

Make the following changes/addition to the draft-ietf-atompub-format-08 
document.

=== section 3.1.1.1 ===

Change:

  If the value is "text", the content of the Text construct MUST NOT 
contain child elements.

To:

  If the value is "text", the content of the Text construct MUST NOT 
contain child elements and SHOULD NOT be empty.

=== section 3.1.1.2 ===

Change:

  If the value of "type" is "html", the content of the Text construct 
MUST NOT contain child elements, and SHOULD be suitable for handling as 
HTML [HTML].

To:

  If the value of "type" is "html", the content of the Text construct 
MUST NOT contain child elements, SHOULD NOT be empty, and SHOULD be 
suitable for handling as HTML [HTML].

=== section 3.1.1.3 ===

Change:

  The XHTML div MUST contain XHTML text and markup that could validly 
appear within an XHTML div element.

To:

   The XHTML div SHOULD NOT be empty and MUST contain XHTML text and 
markup that could validly appear within an XHTML div element.

=== section 4.1.2 ===

Add:

   atom:entry elements SHOULD contain an atom:summary element if the 
atom:content in the form of atomInlineOtherContent.

== Impacts ==

As these requirements are only SHOULDs, no feeds which are currently 
valid will become invalid.  However, those that follow these suggestions 
will find that their feeds are useful to a wider audience than they 
would be otherwise.

== Notes ==

In the event that PaceOptionalSummary is adopted, the words "is either 
not present or" would need to be added to the proposed addition to 
section 4.1.2.

----

CategoryProposals

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 29 Apr 2005 16:21:06 -0700

>textual constructs be both present and non-empty.

+1

>valid will become invalid.  However, those that follow these 
>suggestions will find that their feeds are useful to a wider 
>audience than they would be otherwise.

Folks here know that I'm not a big fan of SHOULDs where a MUST or a 
MAY would be better. In this case, I can see that the changes 
suggested fit the classical IETF definition of SHOULD. We can't force 
you to put in real text because there really might be nothing for you 
to say without just making up gibberish, but you should really try 
hard to say something, even if it is repetitive. You don't know which 
locations the recipient is going to be looking in, as we have seen 
from some of the WG traffic in the past week.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Graham <[email-masked]>
Date: Sat, 30 Apr 2005 10:19:46 +0100

+1

Graham

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 30 Apr 2005 14:05:57 +0100

> providing a textual fallback may lead to interoperability issues.

The bias bothers me - why are the existence of title only feeds 
unfortunate, whereas tools that do not handle them gracefully are not? 
And, is this not the kind of spec text we've been traditionally kicking 
into the Fabled Implementors Guide?

> atom:content in the form of atomInlineOtherContent.

-1 to this addition.

> will find that their feeds are useful to a wider audience than they 

As a rationale, usefulness to a wider audience is debatable.

I'm concerned that this text is intended, or will be leveraged, to call 
out title-only feeds as bad practice. If this is accepted, I would ask 
the editors to take care that is not implied.

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Sat, 30 Apr 2005 10:46:46 -0400

> textual constructs be both present and non-empty.

I'd prefer that a bit more of the rationale made it into the text.
Explain why we are saying SHOULD.

> atom:content in the form of atomInlineOtherContent.

This section needs to be reworked. We can't make normative reference to the RNG.

> not present or" would need to be added to the proposed addition to

-1 to this.

If PaceOptionalSummary is adopted, the summary will be a MAY, not a
SHOULD. Please put your proposals in the section marked "Proposal".

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Sat, 30 Apr 2005 11:15:10 -0400

> Explain why we are saying SHOULD.

Suggestions?  Is this something that the editor can handle?

> This section needs to be reworked. We can't make normative reference to the RNG.

Suggestions?  Is this something that the editor can handle?

> SHOULD. Please put your proposals in the section marked "Proposal".

At the moment, the proposal is based on the existing 
draft-ietf-atompub-format-08.

PaceOptionalSummary does not introduce a MAY, it removes a crucial MUST 
-- one that, if removed, would exasperate the problem that 
PaceTextShouldBeProvided is intended to address.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Sat, 30 Apr 2005 11:23:08 -0400

> Suggestions?  Is this something that the editor can handle?

Maybe Mark can. This editor doesn't understand the rationale.
 
> Suggestions?  Is this something that the editor can handle?

Paces should provide camera-ready text.

> PaceOptionalSummary does not introduce a MAY, it removes a crucial MUST

Obviously, the WG doesn't find that MUST particularly crucial.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Sat, 30 Apr 2005 17:20:36 +0100

> Obviously, the WG doesn't find that MUST particularly crucial.

Robert, will you stop banging your drum about this and let the WG get  
a word in edgeways? If your position has such unanimous support it  
will survive without you.

Thank you.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Sat, 30 Apr 2005 12:36:00 -0400

> will survive without you.

So, I have to be quiet. Is that what you're saying? Let me suggest you
take your own advice.

I wrote six sentences, after a day of no one paying attention to this
pointless, intentionally obfuscated, and otherwise badly written
proposal.

Robert Sayre

On 4/28/05, Tim Bray wrote:
>
> And of course we're going to have to fish some sort of
> consensus out of this horrid summary-required mess.  -Tim

Bill responded
> I can't agree with that observation. Although there are a few strenuous
> objections against title only feeds, on the balance consensus is for
> them. Is there something you're seeing that should make us think the
> current consensus level is inadequate?