Re: Re: The Profile and the Feed Validator

James Holderness wrote:
> 
> 
> Sam Ruby wrote:
>  > James Holderness wrote:
>  >> I think that's going too far. The issue is far more complicated than the
>  >> profile might suggest.
>  >
>  > I previously was told that "We will vigorously defend the profile's
>  > guidance". It that guidance is as incomplete as you indicate, then I
>  > would then suggest that the profile be updated to accurately reflect the
>  > issue.
> 
> I was initially in favour of more detail, but the argument was made that 
> too
> much information would just be confusing, and I think that's a valid point.

Citation?

> We could have something like: "if your title looks like this, then do A, B
> or C; but if your title looks like that, then you should do C, D or E." Or
> we could just say: "the safest option is C". The latter is a whole lot
> easier to understand.

 From what I can recall, the current text is based on what works best 
with existing, popular aggregators.  Or to put it another another way, 
other forms of encoding of things like RSS 2.0 titles and category names 
simply don't work as well.

> Now I'm quite happy to defend that advice for someone creating a feed, but
> that doesn't mean it's a good blueprint for a validator.

What do you think about Rogers' comment that "If the validator 
reinforces our advice, it will force the issue on all of the big stuff..."?

> Perhaps the spec shouldn't have used an uppercase SHOULD in that section.
> Certainly if the feedvalidator is going to treat every SHOULD as a warning
> that would be a problem. Here's one way to look at it though: in the words
> of RFC 2119, there may exist valid reasons in particular circumstances to
> ignore that recommendation (there are). If the feedvalidator were 
> programmed
> to know what those particular circumstances were, it could avoid giving a
> warning.

If people pop up with advice as to what those other circumstances might 
be, I will point them to this mailing list.  If anything emerges out of 
such efforts, I will do my best to factor that input in.  Such advice 
need not be a part of the profile itself, it could be anything that I 
can point to.  I've pointed to a number of posts by yourself, for example.

>  > If this profile is
>  > ratified, many, many, many feeds that work just fine with GoogleReader
>  > and My Yahoo won't conform to the profile; and some of the suggestions
>  > made, if implemented, will break usage with these important aggregators.
> 
> Under certain conditions that can't be helped. Whatever you do, someone's
> aggregator is going to break. The recommendations in the profile favour
> those aggregators that have implemented the spec correctly. Given that my
> aggregator happens to be one of the *incorrect* ones, I'm not exactly
> thrilled by that, but it's a tough sell arguing that we should recommend
> something that would break aggregators that are doing the *right* thing.

Observation: "&#x" is a relatively unlikely string to accidentally occur 
in a feed.  If present anywhere in the feed, it could be taken as an 
indication that character data outside of description and 
content:encoded elements are not to be treated as HTML.  Adopting such a 
policy would mean that you would correctly interpret any feeds that 
match the profile AND would not affect your ability to continue to 
process the overwhelming majority of the remainder of feeds as you do today.

- Sam Ruby


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rss-public/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/rss-public/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/