Tim Appnel: A very productive discussion of an RSS profile has continued throughout the weekend and into this morning. Enthusiastically many have dived in - myself included. I still maintain that an important consideration has not been discussed and needs to. What are our design goals with this profile?
My primary motivation is to discover the best practices that can be codified in the RSS validator. IMHO, people don't read specs unless they have to. And the RSS validator has already noticeably improved the overall level of quality of RSS feeds.
Implementation will likely commence next month. Don's RSS Profile and the RSS Profile Wiki will be taken as input, as well as any others such efforts that we can find.
I agree people don't read specs unless they have to and that the validator has significantly improved RSS feeds over anything else. (I point people there all the time look when the mt-rssfeed plugin chokes on a feed and they contact me for help.) So I concur with what you are doing Sam. It's the right way to go with this.
The use of "design goals" and "design considerations" may not be the best choice of words. I don't want a specification or anything so formal.
In following the recent thread though, I was curious to what is the motivation behind all of the suggestions and +1/-1's. It seemed somewhat arbitrary at times. I don't think it has to though --I see a lot of common themes throughout the discussion so far. (Those where the points I tried to capture in my post.) Would the best practices become more apparent if we had a few higher-level "ideals" (context) in mind as we discuss this? I think so.
Timothy: I actually wouldn't mind if the design goals and considerations were formal. It would give the validator a place to point to when people ask "why?"...
Christian: my experience is that most people "view source" and then copy what they see... possibly referring to the spec when they have a specific question.
Could be a bit of chicken v. egg at work, imo. Because the existing RSS specs are either loose and out of date with what gets practiced (or both, and plausibly, more), examining a good feed firsthand ends up providing better direction (or rounding out what the specs themselves might have been able to provide).
This was my experience personally, I can't say specifically at what point I realized that the specs were't enough on their own, but they were the first destination.
I don't want to post what the first feed on that list not to validate was.
Well-formed XML. We should start a profile for that.