However, without a clear view of where extensibility may occur, extension may break any content formatted to older creole versions.

For example, if a new creole uses the tilde as escape character, or assigns special meaning to leading hyphens (as discussed in the [[List Markup Alternatives]]), then older content will break that contains tilde or leading hyphens without any markup intentions.

I therefore believe that at least for the case of text-based markup, we need an extensibility container, compare [[Generic Extension Element Proposal]].

-- Gregor Hagedorn - 2007-03-09

The pre-1.0 Creole versions are not required to be backward-compatible. We are basically trying out different things, this is beta (or even alpha). Early adopters must consider converting their wikis when the final specification is released.

Once we have the basic markup sorted out, Creole is supposed to be stable -- that is, only very minor chnages or clarifications will occur, possible rewording of the spec, etc.

That's why we are so bitchy -- whatever is decided now will stay.

-- [[Radomir Dopieralski]], 2007-Mar-10

I agree about versions < 1.0. However, do you agree that the problem of wiki markup always using things also occurring in normal text (even if rarely) makes the main [Extensible By Omission] somewhat inappropriate? I believe it does not work for Wiki markup because you cannot truly extended Creole by adding a new markup (e.g. suddenly giving a + at start of line a markup semantics in Creole 2.0).

-- Gregor Hagedorn - 2007-03-14

Wikis have the advantage that even if the rendering of the page degrades for whatever reason (version change, copy-pasting text from other source, adding additional modules, etc.) the users always have access to the source to see what the author meant -- and the first users who notices the fault can even correct it! The rules prohibiting [[InvisibleMarkup]] and requiring [[NonDestructive]] markup aid here a lot.

Remember that we are not dealing with a rigid automated system that has to give the right results 100% of the time, but with a wiki that is by definition fuzzy and fault-tolerant. This doesn't mean we should take this lightly, but I thin that [[ExtensibleByOmission]] is worth the occasional error.

-- [[Radomir Dopieralski]], 2007-Mar-14

The problem is more serious when one adds new features. For instance, if double-comma
is not included in Creole 1.0 and 40 million people begin using it for inline quotes, and
double-comma is added to Creole 2.0, it will be painful to upgrade.

Markup languages like XML or HTML are much safer, because character sequences reserved for
markup are well defined (elements, attributes and entities, that's about it) and a given version
can list them exhaustively.

What we could do with Creole is to list all sequences which are optional (such as double-underscore
for underlined text, single-lessthan for HTML, etc.) or reserved (double-dollar,
double-exclamation mark, or even plus or dollar at the beginning of a line), so everyone knows what
to escape to be safe.

This goes against [[ExtensibleByOmission]], but I agree with Gregor on its limits.

-- [[YvesPiguet]], 2007-Mar-14

That's what I attempted in [[HintsOnExtending]] and what can be done more systematically in [[CreoleAdditions]]. Still I see no problem with leaving out of the specification things like markup inside headings or links.

-- [[Radomir Dopieralski]], 2007-Mar-14

Yes, that's excatly what I meant. The problem with not being explicit enough is that the
author shouldn't assume her markup is guarranteed to stay verbatim in headings, for instance.
In a description of hotels, you should write something like {{{==Hotel du Lac ~*~*~*==}}}
or {{{==Hotel du Lac {{{***}}}}}}{{{==}}} to be safe wrt future Creole versions or engine upgrades.

-- [[YvesPiguet]], 2007-Mar-14