(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 11 added 2 lines
//see also [[http://semanticweb.org/wiki/STIF | STIF @ Semantic Web]]//
At line 42 changed one line
== using only semantic
== using only semantics
At line 44 changed one line
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>).
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 51 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 53 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 62 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 65 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 69 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 71 changed one line
simply the base
simply a base
At line 75 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 78 changed one line
* level 4 : user preference
* level 4 : user preferences
At line 80 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