| At line 1 changed one line |
| ==Proposal== |
| ==Proposal== |
| At line 3 changed one line |
| //See also [[MultilinePlaceholderProposal]] for an alternative.// |
| //See also [[MultilinePlaceholderProposal]] for an alternative.// |
| At line 5 changed one line |
| Support one form of markup, the content of which may be used in any form a given wiki software desires to. |
| Support one form of markup, the content of which may be used in any form a given wiki software desires to. |
| At line 8 changed 3 lines |
| {{{ |
| <<TableOfContents title='Inhaltsverzeichnis' level='2-4'>> |
| }}} |
| {{{ |
| <<TableOfContents title='Inhaltsverzeichnis' level='2-4'>> |
| }}} |
| At line 12 changed one line |
| In the example, the text inside "<<>>" would be meaningful only to a specific Wiki software. The use of "<<>>" conflicts with [[Placeholder]], but see below. An alternative would be to use "{{{[{x}]}}}", mentioned elsewhere as "plugin markup". |
| In the example, the text inside "<<>>" would be meaningful only to a specific Wiki software. The use of "<<>>" conflicts with [[Placeholder]], but see below. An alternative would be to use "{{{[{x}]}}}", mentioned elsewhere as "plugin markup". |
| At line 14 changed one line |
| ==Reasoning== |
| ==Reasoning== |
| At line 16 changed one line |
| One problem of current Wiki software is that content is not portable from one software to another. Much content on the web will simply have to disappear, if the software dies of becomes more and more unreliable, no longer compatible with rest of system setup, etc. |
| One problem of current Wiki software is that content is not portable from one software to another. Much content on the web will simply have to disappear, if the software dies of becomes more and more unreliable, no longer compatible with rest of system setup, etc. |
| At line 18 changed one line |
| While not the primary goal of creole, it appears that the task of migrating content could be hugely simplified by two simple steps. |
| While not the primary goal of creole, it appears that the task of migrating content could be hugely simplified by two simple steps. |
| At line 20 changed one line |
| 1. Creole supports an extension box. The content of this box could then be used in any way a specific wiki software desires to provide dynamic content (indices, backlinks), hidden comments, complex formatting (especially tables), microformats, semantic web markup, special character support, color, css-markup, etc. Anything that is not covered by Creole itself. |
| 1. Creole supports an extension box. The content of this box could then be used in any way a specific wiki software desires to provide dynamic content (indices, backlinks), hidden comments, complex formatting (especially tables), microformats, semantic web markup, special character support, color, css-markup, etc. Anything that is not covered by Creole itself. |
| At line 22 changed one line |
| 2. Creole supporting software optionally supports a Creole-only mode (see [[Levels Of Interoperability]]). |
| 2. Creole supporting software optionally supports a Creole-only mode (see [[Levels Of Interoperability]]). |
| At line 25 changed one line |
| ==Advantages== |
| ==Advantages== |
| At line 27 changed one line |
| The major advantage of this is that with a managing-and-migrating-content use case, only content inside the extension box needs to be transformed. The major problem with migration is that as a side-effect of wiki-markup quite a number of "normal" text needs to be escaped (often occurrences of CamelCase, !=-*# on the first line, [, etc.). With a Generic Extension Element, porting content becomes much easier. |
| The major advantage of this is that with a managing-and-migrating-content use case, only content inside the extension box needs to be transformed. The major problem with migration is that as a side-effect of wiki-markup quite a number of "normal" text needs to be escaped (often occurrences of CamelCase, !=-*# on the first line, [, etc.). With a Generic Extension Element, porting content becomes much easier. |
| At line 30 changed one line |
| ==Disadvantages== |
| ==Disadvantages== |
| At line 32 changed one line |
| * Makes creole larger |
| * Makes creole larger |
| At line 35 changed one line |
| ==Extension/Plugin versus Placeholder== |
| ==Extension/Plugin versus Placeholder== |
| At line 37 changed one line |
| The "<<>>" has already been proposed for [[Placeholder]], and differentiated from a "plugin" markup (which is probably very similar to this proposal, but I found it only mentioned in passing and no proposal). I do not believe that a distinction between the //editing use case// elaborated for [[Placeholder]] (see especially [[Prototype]]) and the //data storage use case// of Extension Element is justified. |
| The "<<>>" has already been proposed for [[Placeholder]], and differentiated from a "plugin" markup (which is probably very similar to this proposal, but I found it only mentioned in passing and no proposal). I do not believe that a distinction between the //editing use case// elaborated for [[Placeholder]] (see especially [[Prototype]]) and the //data storage use case// of Extension Element is justified. |
| At line 41 changed one line |
| The only point of divergence is, if the content is not creole-only, and the editor is creole-only. Then, some content would use software-specific markup, as the {{{[{CapitalizePlugin text='World'}]}}} discussed on [[Prototype]]. However, from a user perspective, it seems more than logical to then handle this (truly-placeholder)-use case with "<<>>" as well. |
| The only point of divergence is, if the content is not creole-only, and the editor is creole-only. Then, some content would use software-specific markup, as the {{{[{CapitalizePlugin text='World'}]}}} discussed on [[Prototype]]. However, from a user perspective, it seems more than logical to then handle this (truly-placeholder)-use case with "<<>>" as well. |
| At line 43 added 46 lines |
|
| -------------------------------------------------------------------------------- |
|
| And here's your text: |
|
| ==Proposal== |
|
| //See also [[MultilinePlaceholderProposal]] for an alternative.// |
|
| Support one form of markup, the content of which may be used in any form a given wiki software desires to. |
|
| Example |
| {{{ |
| <<TableOfContents title='Inhaltsverzeichnis' level='2-4'>> |
| }}} |
|
| In the example, the text inside "<<>>" would be meaningful only to a specific Wiki software. The use of "<<>>" conflicts with [[Placeholder]], but see below. An alternative would be to use "{{{[{x}]}}}", mentioned elsewhere as "plugin markup". |
|
| ==Reasoning== |
|
| One problem of current Wiki software is that content is not portable from one software to another. Much content on the web will simply have to disappear, if the software dies of becomes more and more unreliable, no longer compatible with rest of system setup, etc. |
|
| While not the primary goal of creole, it appears that the task of migrating content could be hugely simplified by two simple steps. |
|
| 1. Creole supports an extension box. The content of this box could then be used in any way a specific wiki software desires to provide dynamic content (indices, backlinks), hidden comments, complex formatting (especially tables), microformats, semantic web markup, special character support, color, css-markup, etc. Anything that is not covered by Creole itself. |
|
| 2. Creole supporting software optionally supports a Creole-only mode (see [[Levels Of Interoperability]]). |
|
|
| ==Advantages== |
|
| * The major advantage of this is that with a managing-and-migrating-content use case, only content inside the extension box needs to be transformed. The major problem with migration is that as a side-effect of wiki-markup quite a number of "normal" text needs to be escaped (often occurrences of CamelCase, !=-*# on the first line, ~[, etc.). With a Generic Extension Element, porting content becomes much easier. |
|
|
| ==Disadvantages== |
|
| * Makes creole larger |
|
|
| ==Extension/Plugin versus Placeholder== |
|
| The "<<>>" has already been proposed for [[Placeholder]], and differentiated from a "plugin" markup (which is probably very similar to this proposal, but I found it only mentioned in passing and no proposal). I do not believe that a distinction between the //editing use case// elaborated for [[Placeholder]] (see especially [[Prototype]]) and the //data storage use case// of Extension Element is justified. |
|
| The data storage use case of software-specific markup will often lead to the editor use case (but an editor may support software specific elements). Conversely, I can not think of an editor use case, that does not go back to software-specific creole extensions. |
|
| The only point of divergence is, if the content is not creole-only, and the editor is creole-only. Then, some content would use software-specific markup, as the {{{[{CapitalizePlugin text='World'}]}}} discussed on [[Prototype]]. However, from a user perspective, it seems more than logical to then handle this (truly-placeholder)-use case with "<<>>" as well. |
.