(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-5) was last changed on 20-Sep-2008 19:07 by spir  

This page was created on 20-Sep-2008 17:43 by spir

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 1 changed one line
//this a first draft of a not-so-deeply-explored idea ;-)//
//this a first draft of a not-so-deeply-explored idea -- [[spir]]\\
At line 3 added 2 lines
----
----
At line 7 changed one line
syntax standard versus file format
syntax standard /versus/ file format
At line 12 changed one line
We are used to contexts where the user interface is disconnected from the 'real' document through personalisation. For instance, an editor allows to set the indent width, whatever you or the author typed, and the save format for indentation (tab or n spaces), whatever you typed. This creates a kind of disconnection of foreground & background, for display as well as for input. One can set what to type (e.g. TAB) for a specific token and/or meaning (indent) ; and conversely how a specific token should be displayed.
We are used to contexts where the user interface is disconnected from the 'real' document through a personalisation layer. For instance, an editor allows to set the indent width, whatever you or the author typed, and the save format for indentation (tab or n spaces), whatever you typed. This creates a kind of disconnection of foreground & background, for display as well as for input. One can set what to type (e.g. TAB) for a specific token and/or meaning (indent) ; and conversely how a specific token should be displayed.
At line 21 changed 2 lines
Could we do that for wikitext/wikiCreole? **Instead of (or together with) promoting a standard source text markup, we may promote a background file saving format**. Then, however the text was typed, it would be saved in a standard form which allows any other form for display and edition.
We may use any kind of encoding for saving. It may even be identical to the present or future wikiCreole markup (once made more consistent, see
Could we do that for wikitext/wikiCreole? **Instead of (or together with) promoting a standard source text markup, we may promote a background file saving format**. Then, however the text has been typed, it will be saved in a standard form which allows any other form for display, as well as for edition.
We may use any kind of format for saving. It may even be identical to the present or future wikiCreole markup (once made slightly more consistent, see
At line 24 changed one line
It may also be more formal, using for instance unique tokens to speed up the rendering process. It may also be directly transcoded to x/html.
It may also be more formal, using for instance unique tokens in order to ease and speed up the rendering process. It may also be directly transcoded to x/html.
At line 26 changed one line
== can it be (easily) achieved ?
//see also [[http://semanticweb.org/wiki/STIF | STIF @ Semantic Web]] : project toward a file exchange format -- but customization not adressed//
At line 28 changed one line
The problem for an internet application is a bit more complicated than for a local one. Not only an encoding/decoding extension is needed for the editor, but there may be several variants, and also the parameters have to be saved somewhere.//
== can it be (easily) implemented ?
//If ever this idea sounds not only romantic to your ears, please help and improve this section, particuliarly, as I haven't ever done such a job. Here is how thez pb looks to my eyes after a brief exploration ://
case of wikitext on a remote server
Not only an encoding/decoding extension is needed for the editor, but there may be several syntax variants, and also the parameters have to be saved somewhere.\\
At line 34 changed 2 lines
The three first cases lie at the site level. About the last one, a preference file could be uploaded ; or, if the user is a registered member of the wiki, they may be stored together with his/her profile. Anyway, it's at most a few hundred bytes of plain text.
//see also above ยง "customization cascade"//
The three first cases lie at the site level. About the last one, a preference file could be uploaded ; or, if the user is a registered member of the wiki, it may be stored together with his/her profile. Anyway, it's at most a few hundred bytes of plain text.
At line 37 changed one line
Then remains the question of encoding and decoding from/to the saving format. The specification itself is the job of the people who promote the standard, but delivering tools to help integrating would help much : a parser. Still, if the format is clear & coherent, its parsing will be easier. Especially, I guess, if the saving format specifies only semantic classes.
Then remains the question of encoding and decoding from/to the saving format. The specification itself is the job of the people who promote a standard, but delivering tools to help complying with it helps much : a parser. Still, if the format is clear & coherent, its parsing will be highly easier. This is especially true, I guess, if the saving format specifies only semantic classes.
At line 39 changed one line
== using only semantic
== using only semantics
At line 41 changed one line
Some of the people who promote plain text structure language standards (not only for wiki) express the opinion that such a language should only specify the semantics of the structure. To do this, not only the language specification must avoid using words who evoke styles ("bold"), but the html transcoding too must not specify any concrete styling (<b>).
Some of the people who promote text structuring markup standards (not only for wiki) express the opinion that such a language should only specify the semantics of the structure. To do this, not only the language specification must avoid using words who evoke styles ("bold"), but the html transcoding must not specify any concrete styling (<b>).
At line 48 changed one line
The above examples don't pretend to be good... ;-) Just for lauching your imagination. Still it should be /much/ easier to reach an agreement on such formal and background Ids than on foreground tags ! End of the tag war...
//The above examples don't pretend to be good... ;-) Just for lauching your imagination. Still it should be /much/ easier to reach an agreement on such formal and background Ids than on foreground tags ! End of the tag war...//
At line 50 changed 3 lines
Such IDs may be encoded directly in real x/html. Anyway, the purpose is only to indicate text types for which styles would be defined separately. If a wiki engine developper or a site admin does not want to use style sheets, it's still possible to encode further to replace classes with concrete styles.
Or we could use any other ad hoc encoding, such as :
Such IDs may be encoded directly in real x/html. Anyway, the purpose is only to indicate text types for which styles would be defined separately. Or we could use any other encoding, such as :
At line 59 changed 2 lines
I was really surprised when I read about the possible mixed mode of implementation for letting wikiCreole coexist with a local wiki dialect. First I thought that, how well designed wikiCreole may be, there would be tag conflicts. Then the right way should be edit Creole mode.
As soon as there a saving standard, instead of an editing standard, this problem simply disappears.
I was really surprised when I read about the possible mixed-mode of implementation for letting wikiCreole coexist with a local wiki dialect. First I thought that, how well designed wikiCreole may be, there would be tag conflicts. Then that the right way should be edit-Creole-mode.
Anyway, as soon as there is a file format standard, instead of an markup standard, this problem simply disappears. Or am I wrong ?
At line 62 changed one line
This would allow wikiCreole to cover most of the needs in wikiText, instead of only a minimum set of common features. Moreover, the standard should rather cover as much as possible, so that when it is used instead of the local dialect, only few remaining, wiki-specific features can't be expressed using standard Creole. This point can also be adressed through customization, using the [[ExtensibleByOmission]] principle.
This would allow wikiCreole to cover most of the needs in wikiText, instead of only a minimum set of common features. Moreover, the standard should rather cover as much as possible, so that when it is used instead of the local dialect, only few remaining, wiki-specific, features can't be expressed using Creole. This point can also be adressed through customization, due to the [[ExtensibleByOmission]] principle.
At line 66 changed one line
Such a method open possibilities of customization at several levels, each one beeing imo a great advantage:
Such a method opens possibilities of customization at several levels, each one beeing imo a great advantage. So that, analog to //cascading// style sheets, there may be //cascading// markup customization :
At line 68 changed one line
simply the base
simply a base
At line 72 changed one line
Adaptation to the engine's own dialect, so that its users can also use Creole more naturally. For instance use '__' for bold or '-' for a list item.
Adaptation to the engine's own dialect, so the authors used to it can also write in Creole more naturally. For instance set '{{{__}}}' for bold or '-' for a list item.
At line 75 changed one line
* level 4 : user preference
* level 4 : user preferences
At line 81 added 7 lines
== pros
//write down//
== cons
//idem//
Version Date Modified Size Author Changes ... Change note
5 20-Sep-2008 19:07 7.604 kB spir to previous moved STIF link
4 20-Sep-2008 19:02 7.52 kB spir to previous | to last
3 20-Sep-2008 18:33 7.406 kB spir to previous | to last re reading in prgress
2 20-Sep-2008 18:14 7.215 kB spir to previous | to last
1 20-Sep-2008 17:43 6.666 kB spir to last first draft
« This page (revision-5) was last changed on 20-Sep-2008 19:07 by spir