On Tue, Jan 4, 2011 at 1:27 PM, Dirk Riehle dirk@riehle.org wrote:
As long as we're hung up on details of the markup syntax, it's going to be
very very hard to make useful forward motion on things that are actually going to enhance the capabilities of the system and put creative power in the hands of the users.
Forget about syntax -- what do we want to *accomplish*?
I think you got this sideways. The concrete syntax doesn't matter, but the abstract syntax does. Without a clear specification no competing parsers, no interoperability, no decoupling APIs, no independently evolving components.
(Abstract syntax here means "XML representation" or structured representation or DOM tree i.e. an abstract syntax tree. But for that you need a language i.e. Wikitext specification and an implementation of a parser as of today doesn't do the job.)
[snip]
In order to have a visual editor or three, combined with a plain text editor, combined with some fancy other editor we have yet to invent, you will still need that specification that tells you what a valid wiki instance is. This is the core data; only if you have a clear spec of that can you have tool and UI innovation on top of that.
Exactly my point -- spending time tinkering with sortof-human-readable-but-not-powerful-enough syntax distracts from thinking about what needs to be *described* in the data... which is the important thing needed when devising an actual storage or interchange format.
Wikis started out as *very* lightly formatted plaintext. The point was to be fast and easy -- in the context of web browsers which only offered plaintext editing, lightweight markup for bold/italics and a standard convention for link naming was about as close as you could get to WYSIWYG / WYSIYM.
As browsers have modernised and now offer pretty decent rich-text editing in native HTML, web apps can actually make use of that to provide formatting & embedding of images and other structural elements. In this context, why should we spend more than 10 seconds thinking about how to devise a syntax for links or tables? We already have a perfectly good language for this stuff, which is machine-parseable: HTML. (Serialize it as XML to make it even more machine-friendly!)
If the web browsers of 1995 had had native HTML editing, I rather suspect there would never have been series-of-single-quotes to represent italics and bold...
-- brion