[JoeMadia, RefactorOk] An invented term used to describe the developers that will be learning this new spec primarily through the process of viewing and copying existing implementations.
The ViewSourceClan appears to be an important target audience for this specification but this hasn't been made an explicit goal. From Escaped HTML discussion: In my experience, people don't read specs carefully, instead they view source and emulate.
I certainly agree people rarely read specs (certainly not at first) but I think the ViewSourceClan is declining. I don't have any hard evidence to back this up, but just try view source 1. on this page; 2. on an RSS feed chosen at random - e.g. Sam's RSS 0.91. Now really, view source (not just as IE renders XML) and imagine how far a total newbie might get emulating that. [DannyAyers]
View source on this page is hardly confusing.
I learnt XML by viewing source. Still do. And implemented RSS by example, too. Please, keep things simple. [LeonardoHerrera DeleteOk]
A longer rant : The Legend of "View Source"
Indeed, the ViewSourceClan appears to be the only target audience for this specification. People have already started generating feeds, but there's not a formal specification in sight -- just a collection of sample feeds and an informal, incomplete list of tags.
Playing with working code (also called prototyping) is a well-known technique for shaking out issues. "Specification up front" has its own set of risks. It is correct to note that the work is not done until a spec exists.
Still, a draft Relax NG grammar in conjunction with a collection of examples would be much more useful for evaluation purposes than a collection of examples by itself. (The draft EchoSchema on this Wiki would also be useful -- if it actually matched the collection of examples
[SimonWillison] I implement based on view-source out of sheer laziness - specs are usually quite hard work to read so copying an example lets me get up to speed quicker. That said, I'm conscientious and would rather get things right when I do implement them. The ideal tool for someone like me is a validator, like the RSS Validator by Mark Pilgrim and Sam Ruby. That way I can implement from examples and then check to ensure I haven't made a foolish error. The biggest problem with validators is finding out about them in the first place - I'm sure there are hundreds of people who implemented RSS by looking at someone elses feed without being aware that a validator existed that they could check their work with afterwards.
(Crazy idea coming up) So... is there any way we could embed knowledge of the validator in to every feed? Maybe something like this:
<feed xmlns="http://example.com/newformat#" xmlns:ent="http://www.purl.org/NET/ENT/1.0/" xml:base="http://bob.blog/" version="1.0" validator="http://validator.necho.org/please-use-this-to-validate-your-feed/" >
The validator attribute ends up being something of a hack - Necho parsers ignore it completely, but it exists in the hope that the ViewSourceClan will be more likely to find out about the validator and use it to ensure their feed is correct. A less hack-ish way to implement this would be with a comment, but comments are much more likely to be left out of feeds as more of them develop. The validator attribute could even be required to remove the likelihood of people leaving it out.
Like I said, it's a crazy idea and a hack but I still think it (or something like it) is worth considering - especially if by doing this we can encourage an early culture of validation within the !echo community.
[AsbjornUlsberg, RefactorOk] Isn't it a much cleaner way to just have an informal HTML page at the namespace URI? Most of these ViewSourceClan-guys doesn't know what a namespace is, and is very likely to open it's URI in a browser. "Hm. A web adress. What's this?". When they plunge the adress into a browser, they should be welcomed to a short and informative little page that explains about what Echo is, about validators, maybe links to tutorials and the formal spec., etc., etc.
View Source and Required Elements
One DesignPattern in support ViewSource is that certain elements be required yet allowed to be empty. This gives people viewing source a checklist of things they should fill in.