On 14/11/2007, Thomas Dalton thomas.dalton@gmail.com wrote:
I'd pick the one that better enables third-party implementations from the spec. If there's nasty stuff to do as well, at least it can be specified nasty stuff, with public-domain pseudocode to work from and so forth.
I'd say they're equally good from that perspective. Steve's idea is probably slightly easier to specify simply. My idea would allow 3rd parties to simply not allow invalid syntax and then not worry about tidying it (basically, we have two specs, a strict one and a tolerant one). If their users are slightly more tech-savvy than ours, requiring they use well-formed wikisyntax would be acceptable, if not, then they'll have to do something just as messy as us.
Third party parsers will first be used by third party MediaWiki installations. For things like office intranets, whose users will make a technophobic Wikipedian look like a geek by comparison.
I beg you, think of the sysadmins! ANY error will make more work for them. Then they'll install MoinMoin instead. Then their lives will suck.
Does *any* wiki engine throw errors at bad wikitext, or just give glaringly malformed results? I really think glaringly malformed results are all the error message a user needs. And anything that doesn't cause a glaringly malformed result is not an "error" in the first place. That's the "tag soup is a feature" theory.
I realise something that throws errors is easier to implement, but that's not enough justification IMO.
- d.