On 02/06/2012 11:03 AM, Pavel Tkachenko wrote:
2012/2/6 Trevor Parscal
<tparscal(a)wikimedia.org>rg>:
I hope this effectively illustrates an
alternative perspective on this
subject. This is a very hard problem, and any course of action will involve
some level of risk. We are trying our best to manage this risk, mostly by
conducting a great deal of research and development.
This is understandable, the
scale of problem is as such that it is
inappropriate to take any action in one instant.
I cannot say that your arguments have given me much to think about due
to lack of specifics but I'm glad if they're more elaborated on the
core level.
Still, I cannot see why it's impossible to first create a solid
foundation without drastically changing everything and then build
visual editor and other high-level structures on top of it.
The parser we are working on [1] should eventually give us the solid
foundation you are lobbying for. It is strongly motivated by, but not
technically tied to the visual editor. The enriched HTML DOM we are
building (and actually most token stream processing including template
expansion) is not tied to any specific syntax or user interface.
We do currently add some round-trip information to support a very
gradual normalization of WikiText formatting without non-localized dirty
diffs. Anybody wishing to experiment with an alternate markup UI could
however ignore this issue initially, which should simplify the task a
lot. Alternate markup-based user interfaces would require a different
serializer and tokenizer, but can share the remaining parser pipeline,
so this simplified task should indeed be quite manageable.
But in any case, we first have to implement a solid tokenizer for the
current syntax and recreate at least a part of the higher-level
functionality (template expansion etc) based on a syntax-independent
representation.
Gabriel
[1]:
https://www.mediawiki.org/wiki/Future/Parser_development