//this a first draft of a not-so-deeply-explored idea ;-)//
//feel free to correct & clarify my weird english ;-)//

{{{
markup customization : an alternative to syntax standard ?
or
syntax standard versus file format 
}}}

== extended customization

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.

This principle may be extended to allow a real customization of any computer language. For instance, I would set that an assignment should be written ':' rather than '='. This is what I would see and type in the editor. Still the assignment is saved in file as "=" or any other standard token. Note that this method allows for keyword changes as well, including an internationalisation of the whole programming language. I also would change "print" (!) to "write", "écrire", "escriure" or "schreiben".

Most important, as the saved version is standard, any user or programmer who opens a file written by someone else would read it as expected : that is either according to the standard norm, or to his/her own customized one -- not according to the author's preferences, whatever they may be. The editor simply replaces standard tokens of the file by tags, signs or keywords defined in a local parameter file. The editor simply search-and-replaces standard tokens by the ones set in a local parameter file.
Only when the syntax, not only the lexicon, is changed, then the problem becomes much more difficult and requires real parsing. Or do I misunderstand the point ?

== application to wikitext

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
[[http://www.riehle.org/wp-content/uploads/2008/01/a4-junghans.pdf]]). 
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.

== can it be (easily) achieved ?

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.//
There may be be several norms for a user to choose when about to edit :
* the site's own dialect
* standard Creole
* a local Creole variant (e.g. using tokens closer to the local dialect)
* the user's own preferred norm
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"//

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.

== using only semantic

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>).

This requirement is achieved by specifying only semantic classes instead, whose names or IDs can be clear, unambiguous and functional. For instance :
* "litteral_block_of_text" (nowiki, unprocessed)
* "important_segment_of_text" (or simply "highlighted", but better avoid x/html vocabulary)
* "link_or_pointer_target" (= anchor, note or reference)

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...

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 :
{{{
Still it should be <segment_style : distinct_text>much</segment_style : distinct_text> easier to reach an agreement...
}}}

== relation to "native" dialect

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. 

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.

== customization cascade

Such a method open possibilities of customization at several levels, each one beeing imo a great advantage:
* level 0 : creole standard\\
simply the base
* level 1 : internationalisation\\
Allows to choose alternative tags for a better adaptation to various cultures (e.g. "#" as number sign is cultural) ; but also to use keywords, as they would then be translatable : [[keywords for internationalisation]].
* level 2 : wiki engine level
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.
* level 3 : site level
This level allows customization to any local variant, especially to topic-specific formatting needs. This can be done using an [[GenericExtensionElementProposal | extension syntax]] -- particuliarly useful for additional inline elements or block components.
* level 4 : user preference
For any weird reason, users always find defaults in any standard, have their own opinion on anything, want to change things that proved to be good...