On 14/11/2007, Thomas Dalton <thomas.dalton(a)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.