On 3/7/07, Jared Williams <jared.williams1(a)ntlworld.com> wrote:
That requires fixing the grammar which is ambiguous.
Which has already been
ruled out by Brion, at least for the foreseeable future.
To the contrary, Brion has stated that developing a formal or
semiformal grammar and tweaking the syntax to fit would be a great
thing. He's just stated that any substantial change to the syntax
(like Wikicreole) is out of the question for the foreseeable future.
On 3/7/07, Mark Clements <gmane(a)kennel17.co.uk> wrote:
In this example I don't think this is a problem -
the parser neatly fixes
any ambiguous syntax. However there may be situations where this matters.
I would be interested to see if anyone can come with a good example.
How about:
I love <i>'potatoes'</i>!
That will become what? I love '''potatoes'''!, naively. It
could
become I love ''<nowiki>'potatoes'</nowiki>''! or
something, sure, but
that kind of weird case is something the XML-to-wikitext parser will
automatically have trouble with, because wikitext makes no clear
distinction between data and markup.
Sure, you could say, you just have to escape all possible literal
markup characters and then unescape unambiguous characters after
you're done, or whatever. The worry is that there might be cases that
are much harder to fix, if not impossible, and we won't really know
for sure until someone takes the plunge and tries to write it.
Remember, too, that there are plenty of cases where behavior of the
parser is basically undefined, and so you should identify all such
constructs and either avoid them or define their behavior.
I suppose I'm kind of out of my depth to say how we should avoid this
(not a first on this list), but formalizing the grammar is surely a
good first step to eliminate bizarre behaviors and make the task of
figuring out a mapping easier.
On 3/7/07, George Herbert <george.herbert(a)gmail.com> wrote:
Essentially, right now we're optimized for
editing. Structurally, we
could do an intermediate closer to HTML and do less
transform-on-display, but to do that and keep Wikitext would require
transform-on-edit and transform-on-save, which we basically don't have
to do now.
Unless WYSIWYG is the standard, and wikitext optional. Then most
people will use WYSIWYG, which can modify the XML directly (and render
it directly via XSL) and send back prevalidated XML. But that's
probably more of a side benefit.
On 3/7/07, Platonides <Platonides(a)gmail.com> wrote:
However there
may be situations where this matters.
I would be interested to see if anyone can come with a good example.
templates?
templates including inline syntax?
How do you store templates? as XML to revert or as wikitext?
<template src="Template:Person">
<param name="age">42</param>
<param name="birthplace"><link target="New York
City">New York
City</link></param>
. . .
</template>
On 3/7/07, Mark Clements <gmane(a)kennel17.co.uk> wrote:
My strategy for all transclusion or dynamic content
(magic words, parser
functions, etc.) would be to keep it in some unexpanded form that is filled
in when the page is output. My initial thought was to embed it in special
comments (a la Dreamweaver) that get parsed and rendered before the page is
sent to the browser, but I'm sure there are better ways. For example,
{{MyTemplate|bar|myarg=foo}} might be stored as <!--MWTemplate
_source="dab"
_1="bar" myarg="foo" -->.
No, using comments for semantics is evil. They're against standards
and (partially) defeat the purpose of using XML in the first place,
namely parsing via standardized functions.
On 3/7/07, Mark Clements <gmane(a)kennel17.co.uk> wrote:
"Steve Sanbeg" <ssanbeg(a)ask.com> wrote
in message
news:pan.2007.03.08.00.37.53.753612@ask.com...
How about just having an XML definition of the
current wiki syntax. I.e.
convert that as
<begin-italic/>test<eol/>
or even something like
<begin-italic/>test<end-italic implicit/><eol/>
which would keep more of the logic in the parser, while still being
reversible.
That is, keep all of the structure; don't actually render it, but allow it
to be rendered with a straightforward transformation, and not an FSM or
such.
That's an interesting suggestion. I would be interested to see a bit more
work in this area... is there anything that couldn't be handled by this?
Probably not, but it will still be tricky to reverse (see my love of
<i>'potatoes'</i> above). And if all your tags are self-closed, you
aren't using XML's hierarchal model, so I don't know if there's much
point in bothering with such a heavyweight syntax. You just need some
consistent escaping to distinguish between data and markup, if you
aren't going to enforce pairing and structure as "proper" XML
requires. (You'll still need stuff like uniqueness of id's, fine, but
it still partly defeats the point of simplicity of parsing/rendering,
I would think.)