17 Jan
2009
17 Jan
'09
2:55 p.m.
On Jan 17, 2009, at 12:11 PM, Pascal Voitot wrote:
No we would be compliant. Only in one direction.
Yes that's option 2 I proposed.
Yes if we had to choose another syntax to support we would probably
pick mediawiki IMO since lots of xwiki users are coming from there.
The first step is to implement the link parser for the mediawiki
syntax. Once this is done we're already covering about 80% of the
mediawiki syntax.
Back to the topic I think it's not too hard for the GWT editor to work
based on syntax capabilities. The editor dev team should have this in
mind but I don't think it's our priority. Once the first final release
of the GWT editor is done in march then we could introduce this for
other syntaxes.
-Vincent
On Sat, Jan 17, 2009 at 11:36 AM, Vincent Massol
<vincent(a)massol.net> wrote:
We have that already and we're not developing the other parsers.
They're already developed. Only problem is that they're buggy.
On Jan 17, 2009, at 10:54 AM, Pascal Voitot wrote:
It might even become crazy to support...
*One wiki to rule them all, one wiki to find them, one wiki to bring
them
all, and in the darkness bind them.*
We know the end of the story :) So, Maybe, it would be better to
propose an
nice API to add a new syntax parser. Some questions arising in my head:
do you want to make the WYSIWYG the cornerstone of XWiki online
editing or
is it only the XWiki2.0 syntax editor?
do you want to make multi-syntax a key feature of XWiki or is it
only a
facility provided so that people can use easily XWiki and when they
are used
to it, they will naturally begin to use XWIki2.0 syntax?
If WYSIWYG is used only with XWiki2.0 syntax, it might look like you
are
strongly encouraging people to use XWIki2.0 syntax instead of other
syntaxes. Is it a good or bad strategy? I don't know... to be
discussed :)
IMO we must strongly encourage people to use the xwiki 2.0 syntax and
the other syntaxes are only a facility (at least for now and the
foreseeable future IMO). Reasons:
1) it's hard to fix all parsers for all syntaxes Some people might be interested in
developping the parser for their own needs and provide it to the
community.
Sure. All we need is to write a tutorial.
2) other
syntaxes are all way less powerful than the xwiki syntax.
for this point, I trust you :)
3) there are issues with links in other syntaxes. For ex the ability
to link to multi wikis which doesn't exist in most syntaxes so
they'll
only offer a very small subset of xwiki linking features and you
wouldn't be able to link between wikis. Unless we extend other
syntaxes of course (need to find syntax for doing that and write link
parsers for that)
If you extend other syntaxes, I'm not sure their creator will be happy
and you won't be compliant anymore with the real syntax. The problem is also that other syntaxes will continue
their
evolution. If
you want to keep compliance, you will have to support these
modifications.
It's an endless and non-sense work...
That's fine and ok since this is a community effort. It's not like
we're deciding to write parsers for all syntaxes.
Being a "meta-something" (meta-wiki in our
case) is always nice on
paper but
it's rarely a possible project...
It's really not far since there are already those other parsers
existing. Right now the main thing missing is the link parsers.
Finally, xwiki2.0 syntax might be the most powerful
syntax today but
tomorrow, will it be true?Could it happen that the wysiwyg proposes a
feature for a specific syntax that is not supported by xwiki2.0?
No since we're developing it with xwiki 2.0 syntax in mind.
Also it doesn't matter if some other syntax becomes more powerful
since that would work with the WYSIWYG editor (provided it's a
superset of the xwiki 2.0 syntax). Also we can have a xwiki 3.0 syntax
so there's no problem there.
4) the new
wysiwyg only works well with the 2.0 syntax
It could evolve progressively so that this dependency is lazier and
so that
one could add another syntax to the wysiwyg, deactivate unsupported
features
from the interface etc... 5) We'd
need to write syntax renderers for all syntaxes if we want
them to be equal to the xwiki 2.0 one but if we do so then we have
the
issues raised in 2).
As time progresses we'll probably improve other syntax support but
right now we must encourage people to use the xwiki 2.0 syntax as
much
as possible and consider the other syntaxes as migration strategies
IMO.
I think you are writing "xwiki", not "xwiki for confluence users"
for
example... So it's certainly better to promote your syntax which
corresponds
to your vision, your architecture and your way of thinking...
But to bring compatibility with other syntaxes, I don't know what's
the best
way: to write converters or to support the syntax directly in the
editor...
The second option is quite sexy but it might be impossible to
support. I
would say: "This is a marketing choice! What other syntax do we need
to
support so that people tend to use our product and increase our market
share?"... Oh sorry I forgot this is an opensource project :)... But
maybe,
you could think about supporting one or 2 other well-chosen syntaxes
which are commonly used to attract some people to XWiki and bring
their new
ideas to our community!
Pascal
>
> WDYT?
>
> Thanks
> -Vincent
>
>> Pascal
>>
>> On Sat, Jan 17, 2009 at 10:07 AM, Vincent Massol
>> <vincent(a)massol.net> wrote:
>>
>>> Hi,
>>>
>>> Just realized that our new WYSIWYG editor will only work fine with
>>> our
>>> xwiki 2.0 syntax since other wiki syntaxes are less powerful and
>>> won't
>>> be able to express some complex structures (like embedding a
>>> document
>>> inside a table cell) or simply like styling a portion of text.
>>>
>>> Of course this is not a problem of the wysiwyg editor per see but
>>> in
>>> practice it means that users using it for other syntaxes when they
>>> save will get a different rendered result.
>>>
>>> So I"m tempted to say that our GWT editor will only work for the
>>> xwiki
>>> 2.0 syntax and that for the other syntaxes users will have to use
>>> the
>>> wiki editor.
>>>
>>> WDYT?
>>>
>>> Thanks
>>> -Vincent