(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-17) was last changed on 18-Oct-2007 19:14 by YvesPiguet  

This page was created on 26-Feb-2007 20:03 by 77.128.31.184

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
==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 &quot;&lt;&lt;&gt;&gt;&quot; would be meaningful only to a specific Wiki software. The use of &quot;&lt;&lt;&gt;&gt;&quot; conflicts with [[Placeholder]], but see below. An alternative would be to use &quot;{{{[{x}]}}}&quot;, mentioned elsewhere as &quot;plugin markup&quot;.
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 &quot;normal&quot; 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 removed 47 lines
The &quot;&lt;&lt;&gt;&gt;&quot; has already been proposed for [[Placeholder]], and differentiated from a &quot;plugin&quot; 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=&apos;World&apos;}]}}} discussed on [[Prototype]]. However, from a user perspective, it seems more than logical to then handle this (truly-placeholder)-use case with &quot;&lt;&lt;&gt;&gt;&quot; as well.
--------------------------------------------------------------------------------
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=&apos;Inhaltsverzeichnis&apos; level=&apos;2-4&apos;>>
}}}
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==
At line 88 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=&apos;World&apos;}]}}} 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.
Version Date Modified Size Author Changes ... Change note
17 18-Oct-2007 19:14 7.488 kB YvesPiguet to previous Double angle brackets have been accepted
16 18-Oct-2007 17:18 7.466 kB ChuckSmith to previous | to last accepted in Creole Additions
15 26-Sep-2007 09:47 7.41 kB ChuckSmith to previous | to last restore
14 26-Sep-2007 02:05 7.438 kB 161.200.255.162 to previous | to last
13 26-Sep-2007 02:01 7.424 kB 161.200.255.162 to previous | to last
12 15-Apr-2007 12:30 7.41 kB GregorHagedorn to previous | to last
11 15-Apr-2007 12:24 7.254 kB GregorHagedorn to previous | to last
10 15-Apr-2007 12:22 7.132 kB GregorHagedorn to previous | to last
9 28-Mar-2007 10:29 7.114 kB Gregor Hagedorn to previous | to last minor revisions, and moving ideas from discussion into proposal
8 27-Mar-2007 18:31 5.546 kB 194.94.56.12 to previous | to last Revision of proposal by Gregor
7 02-Mar-2007 15:37 3.238 kB 194.94.56.12 to previous | to last Clarified: proposed as inline, multiline element
6 02-Mar-2007 15:35 3.207 kB 194.94.56.12 to previous | to last Clarified: proposed as inline, multiline element
5 02-Mar-2007 15:06 2.988 kB 194.94.56.12 to previous | to last typos corrected
4 02-Mar-2007 15:02 6.325 kB 194.94.56.12 to previous | to last typos corrected
3 02-Mar-2007 14:58 2.989 kB 194.94.56.12 to previous | to last
2 26-Feb-2007 20:37 2.981 kB YvesPiguet to previous | to last Cf. MultilinePlaceholderProposal
1 26-Feb-2007 20:03 2.912 kB 77.128.31.184 to last
« This page (revision-17) was last changed on 18-Okt-2007 19:14 by YvesPiguet