On 5/5/05, Sam Ruby <[EMAIL PROTECTED]> wrote:
>
> > This Pace is incompatible with PaceOptionalSummary and incomplete. -1.
>
> Something a little less curt would be appreciated.
>
> The stated abstract of PaceOptionalSummary (i.e., "removing the
> requirement for <atom:summary>") is met. In your mind, this equates to
> completely optional. That has yet to be conclusively established.
Well, consider the name of the Pace, and then consider this sentence:
5. MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional.
It would be deeply bogus to accept a Pace whose sole action was to
remove a normative requirement, and simultaneously accept a Pace that
puts it back in. Seems obvious to me.
> What concerns me more, however, is that interoperability issues that
> PaceOptionalSummary not only creates, but also uncovered during its
> discussion.
We know exactly what issues optional content has, because all of the
other formats have it.
> Unless there is some plan for addressing these interoperability issues
> (and by that, I mean something more constructive than "That's fine, but
> we're not here to tailor the format to your app."), then perhaps BOTH
> paces are incomplete.
Let's enumerate the issues, rather than insist they exist. Frankly, I
seriously doubt that anyone with customers will outright reject a
title-only feed.
> There are a number of ways to finesse the identification of the issue
> into the spec. For example, take a look at how Tim worded
> PaceAllowDuplicateIDs. Producers are put on effectively put on notice
> that if they include multiple entries with the same ID, that some or all
> of them may be ignored.
I don't think PaceAllowDuplicateIDs successfully finessed the issue.
> How should we convey a similar sentiment about the reality that entries
> without a readily available textual representation may suffer the same fate?
So, we're looking for some way to say "provide as much information as
you can." The problem with saying SHOULD is that we purport to know
how much information the publisher can provide. It would be very easy
to explain this issue in the spec, and I have no objection to doing
so. Why do we need the RFC2119 words?
Robert Sayre
