(anonymous guest) (logged out)

Copyright (C) by the contributors. Some rights reserved, license BY-SA.

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 

Add new attachment

Only authorized users are allowed to upload new attachments.

This page (revision-7) was last changed on 21-Apr-2007 15:26 by ChristophSauer  

This page was created on 26-Feb-2007 02:44 by 85.221.141.46

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 1 added 6 lines
== 2007-02-25
[[Gregor Hagedorn]] I found this resource today and looked through it, being a content rather than system person. I like the ideas and hope this wins more support. I do not understand what is intended with Placeholder on [[Creole 0.5]], please elaborate. I wrote [[Levels of Interoperability]], please someone link it in - or ignore if out of scope - I cannot find a good parent place. I wrote a list of some markup wishes and comments on my [[GregorHagedorn|personal page]].
---------------------
At line 17 changed one line
If you want to put formatting inside links because it is meaningful -- how are you going to encode that formating in the page's title? Most wiki engines have pretty strict rules regarding page names, Creole has no power to force the developers to extend them. Lack of formatting inside links encourages users to pick a representation that will not be lost in the page title -- due to formatting being stripped to fit the page naming rules. It's similar to why headings don't have to contain links.
If you want to put formatting inside links because it is meaningful -- how are you going to encode that formatting in the page's title? Most wiki engines have pretty strict rules regarding page names, Creole has no power to force the developers to extend them. Lack of formatting inside links encourages users to pick a representation that will not be lost in the page title -- due to formatting being stripped to fit the page naming rules. It's similar to why headings don't have to contain links.
At line 25 added 2 lines
* Comment GH: No formatting in page-name links is fine, but in my opinion formatting in alternate display text is necessary. Clearly, issues with page names exist as well, but they are secondary. User's understand that this is a technical issue, whereas they complain if some text, just because it links to another page, cannot be written in the way that is expected for science writing.
At line 33 added 2 lines
* Comment GH: I agree - who would not :-)
At line 42 added 32 lines
----
Many thanks for you comments, Radomir!
You say it is not on the agenda, but I still hope to inspire some thinking about content migration and interoperability. I have wikis with a total of 10000 pages online under JSPWiki and feel locked-in to this software. I cannot currently afford to analyse all content, deescape everything that need escaping under JSPWiki, and reformat to a new Wiki style.
I do hope, that even as a minor consideration, making Creole help for these case would be useful. To achieve that, it is essential that Creole can be used as Creole-only markup, with all Wiki-specific stuff moved into a Creole-defined extension mechanism.
The real problem is the need to escape so much "normal" usage of Wiki-specific characters in normal text. If the native wiki markup is on, the full set of this markup has to be analyzed, and all text conflicting with this properly escaped. Unfortunately, the assumptions that Wiki markup does not occur in normal text are, in my experience very optimistic.
If on the other hand, I had a generic extension-box, say "<<>>", then I could use Wiki-specific features inside this box. Of course, moving content would require to migrate the features inside the extension box, but it would not affect the rest of the text (deescaping, escaping).
Gregor, 2007-02-26
----
As for wiki engine interoperability, I see one possibility as being able to have a converter for each wiki engine to Creole. Then, you would, of course, lose the advanced formatting options of that particular wiki engine, but you would then have the freedom to move with that converted Creole to another engine which supports Creole, if you so choose. In any case, I don't see this as coming any time soon, but it is a possibility in the future of wikis and freedom of moving to another engine. Now it's virtually impossible to move from one wiki engine to another, because you'd have to convert from one type to another and the likelihood, for example, of a Trac wiki syntax converter to a DokuWiki syntax converter is very low.
-- [[Chuck Smith]], 2007-Mar-07
Chuck, do you agree that it is worth define a Creole-extension element, allowing Wikis to support the things they need or want (dynamic plugins, special markup, etc.) inside this? My worry is that if Wikis cannot support a Creole-only mode, then the escaping (and de-escaping) of all the Creole plus Wiki-specific markup rules becomes a nightmare.
-- Gregor
Could you describe in more detail (perhaps with an example) of what you mean? From how I see it, this is clearly covered by [[Extensible By Omission]]. It seems to me if someone were to convert a wiki with non-Creole elements to Creole, one would have to somehow translate them to Creole or at least to [[Creole Additions]]. I'm not sure I'm making myself clear here, but I think after seeing an example of what you're referring to, I will be able to better answer you.
-- [[Chuck Smith]], 2007-Mar-07
Thanks Chuck, I have added talk to [[Extensible By Omission]], that I hope makes my point clearer. I agree with the extensibility in part -- the real problem is the escaping of things that used to be literal, and now have special meaning. My main concern in the discussion above is, that without something like [[Generic Extension Element Proposal]] it will not be possible to have optionally have Creole-only wikis, and that means that the set that has to be analyzed when changing software -- sometimes even wiki version or creole 0.5 to 1.0 -- is the superset of the native wiki markup plus creole markup. Anything that occurs in either, has first to be escaped where occurring in normal text. And later de-escaped, before reescaping for a different superset on another wiki. [[Generic Extension Element Proposal]] fixes this in my mind to a very large degree. It will not force anything on developers, but is suggests a standard way to solve the problem I am describing.
-- [[Gregor Hagedorn]] - 2007-03-09
Version Date Modified Size Author Changes ... Change note
7 21-Apr-2007 15:26 8.709 kB ChristophSauer to previous moved gregors introduction from talk to here.
6 09-Mar-2007 23:56 8.188 kB 77.128.50.33 to previous | to last Extensible By Omission is not enough
5 08-Mar-2007 17:28 7.168 kB ChuckSmith to previous | to last Extensible by Omission?
4 08-Mar-2007 17:19 6.654 kB 194.94.56.12 to previous | to last
3 07-Mar-2007 09:55 6.293 kB ChuckSmith to previous | to last possibility for interoperability
2 26-Feb-2007 18:36 5.517 kB 77.128.31.184 to previous | to last
1 26-Feb-2007 02:44 3.743 kB 85.221.141.46 to last welcome
« This page (revision-7) was last changed on 21-Apr-2007 15:26 by ChristophSauer