Hello,
I think this debate might happen on the wrong level. If wikitext is
going to be replaced the new language should be designed on an
abstract level first. If I understand some messages on this list,
maybe the current parser work will provide a DOM scheme which will be
able to represent about all wiki pages. This is necessary for the
Visual Editor.
If this scheme is consistent and feature complete then we can say that
we have _the_ "data model" for wikis. If you have a good DOM data
model with enough documentation, a single summer of code student can
write you a parser for your syntax of desire. And I suspect (need to
think a bit more about it) that if you come up a DOM solution for
representing a wikitext, than that stuff can serve also as a context
free grammar.
So the real question is whether a new-gen wiki syntax will be
compatible with a consensual data model we might have in the future.
Best,
Mihály
On 8 February 2012 13:31, Pavel Tkachenko <proger.xp(a)gmail.com> wrote:
Amir,
Your idea doesn't sound that utopian or crazy to me but, IMO, it has
its weak points.
First, it's a superstition that XML is the only standard way of
representing information. The fact that even after its heavy lobbying
by the-company-we-all-know-about languages like YAML still appear
means that not all people are happy with XML. Similarly,
textile/markdown//bb-codes/wikitext and a dozen of others including
latex, *nix man pages, etc. are appearing even after HTML has been
around for decades.
What is a standard? This is a set of rules. Strict ABNF schemes. UML,
if you please. Can you call Windows INI files "standard"? Yes, albeit
they have just a few entities. And YAML? TeX? Yes. And PDF? EPS? Yes,
and they're even unreadable by humans.
Similarly, wiki markup can be standardized. Creole is meant to be a
standard but it's limited; however, the direction is right and can be
voted for. I am ready to personally standardize and unificate wiki
markup if only to prove my point.
Second, by dividing people into those who "can write texts using a
visual editor" and those who "have to write texts using a storage
format" you're making the same discrimination towards "geeks" that
"geeks" are currently making towards "common folk" by providing
nothing but a text field for writing articles.
Let's put this plain: XML and mostly (X)HTML (SGML at a whole) are
storage formats. This is why they have namespaces, DTD and other
features. But they are generic and while this is an advantage (even
binary data can be stored in some form there) when it comes in touch
with humans things break or just don't move.
This is because XML and friends are not problem-based solutions. While
I have to agree that editing texts might be easier by some people
using a rich editor I cannot agree that editing them in plain text
form must be limited to storage formats. Have you tried hexediting an
article? Having to perform codepage conversions (read, layout changes)
in your mind at the same time. This is the same.
Going further into this looks like speaking about personal taste for
colors and forms so I will just summarize it up: let's leave everyone
with their tool. We have three groups of "users": machines, who
process the text - they're fine with XML or BAML all alike; users, who
need a visual editor to "parse markup" as was said on the neighbor
thread; and someone in between, "geeks", who are enough humans to
dislike XML and enough technicians to despise WYSIWYG.
This seems fair and not that big deal to implement because you'll get
the first and last "markups" ready by definition to have a working
parser (something to store trees in and something to input them using)
and the middle (visual editor) will come in naturally given the other
two.
Signed,
P. Tkachenko
2012/2/8 Amir E. Aharoni <amir.aharoni(a)mail.huji.ac.il>il>:
Honestly, if i'm allowed to speak out my
crazy optimistic utopian
dream, then: <crazy-optimistic-utopian-dream>i want the current-style
wiki markup to disappear completely. I'm referring to *,
'''''', {{}},
[[]] etc. It was very beneficial for the beginning, because it was for
the most part more intuitive to type than <ul><li></li></ul>,
<strong></strong> and <a href=""></a>, but for people
who want
easiness, the Visual Editor is supposed to provide it and after that
most of them should never look back to the markup.
For people who will want text-based markup, it should be mostly XHTML.
So, <section>, <poem>, <source>, and <nowiki> are kinda XHTML so
they
can stay. *, '''''' and [[]] are not XHTML, and they can and
should be
replaced by XHTML, althogh. And {{}} needs its own markup, but it
should be XHTML-like <template name="citation needed" />.
So there. My idea of a bright wikifuture is less home-grown parsers
and more standards. It's easier for the developers and works
organically with the browsers. It's not necessarily easier for people
who want to write articles in plain text with markup, but hey, they
asked for it.</crazy-optimistic-utopian-dream>
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
_______________________________________________
Wikitext-l mailing list
Wikitext-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitext-l
_______________________________________________
Wikitext-l mailing list
Wikitext-l(a)lists.wikimedia.org