On Mon, 22 Jan 2007 20:31:44 +0000, Mark Clements wrote:
"Virgil Ierubino"
<virgil.ierubino(a)gmail.com>
wrote in message
news:24dce9db0701211957k752c1b69oec2d75ffbb4e5a68@mail.gmail.com...
On 1/22/07, Gerard Meijssen
<gerard.meijssen(a)gmail.com> wrote:
Personally, I'm intrigued. Virgil, could you elaborate on the purpose
of this project? In what ways can it help us (and who exactly is the
'us' in this case :))?
As explained already, an EBNF of Wikitext will allow for expansion of
Wikitext easily as it's conforming to a standard, and a more efficient
parser, etc. I'm not the expert in WHY it's good though, I just know it
is.
And I know how to write EBNFs, and I can't
work out how to code Wikitext's
bullet points in EBNF - if EBNF can't handle Wikitext, then the efficient
parsing and expansion won't be possible (as easily).
Would very much appreciate help from anyone clued up as to how to proceed
if
Wikitext can't be EBNFed, or who can show me
that it, in fact, can.
http://meta.wikimedia.org/wiki/Wikitext_Metasyntax
I missed the beginning of this thread for some reason.
Please also see
http://www.mediawiki.org/wiki/Markup_spec and its sub-pages
for some work that has already been done in this area. It would be useful
if you could merge your new page on meta into this existing content.
- Mark Clements (HappyDog)
To try and answer some of what was said before;
No, I don't think wiki text can be fully EBNFed. Basically, an EBNF is a
formal specification for a well defined grammar. The idea is that the
grammar is defined by the specification, and parsers can be written for
it.
Currently, wiki follows the perl model; *the* parser defines the
grammar, and any ambiguities are resolved by seeing how the parser deals
with them.
The way to proceed would be to first specify (EBNF) the unambiguous parts
that can be easily specified, then tweak the parser so that the
grammar would match the specification.
The advantage of doing this is that the grammar is then tied to a formal
specification, instead of a parser implementation, so different
implementations could parse the exact same grammar. (i.e. currently, if
you had parsers in php, perl, & C, they would handle a few corner cases
based on peculiarities of the language, so they would technically
implement 3 slightly different grammars, which would hopefully be close
enough).