| 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// |
|
| 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 ? |
| == can it be (easily) implemented ? |
| 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.// |
| //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 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 too must not specify any concrete styling (<b>). |
.