[wiki-standards] Re: wiki-standards Digest, Vol 22, Issue 10

[Mike Haseler]

> No one is going to sign up to a standard that explicitly prevents them
> adding variations.
> 
Chuck,

I'm not saying the standard should exclude extensions, I'm saying it 
should define how extensions are included.

> Not even the W3C have been able to force people not to embrace and
> extend HTML for their own purposes, and they have a lot more clout
> than WikiCreole.
> 

The difference between HTML and Creole, is that HTML is intended for the 
expert who must know HTML to produce a page, whilst Creole is intended 
for the amateur who need not know Creole to produce a page of text.

There are a number of ways you could achieve arbitrary extendibility 
within a very tight specification:

1. You could define tokens as being two or more symbols (excluding some 
!!! and ??? which are used to enliven text). And then define a few whose 
meaning is application specific e.g. %% (not checked if this is used).

2. You could define a token string which is always application specific:

i.e. <<MORE_TOKENS....arbitrary text..>> for formatting of the arbitrary 
text which is to be displayed as text when the parser does not 
understand or cannot reproduce the format and:-

<<<...Anything_you_like_as_long_as_it_is_not....>>>

For blocks of code which will be ignored if they are not understood.

Obviously the choice of tokens would need to be carefully accessed, but 
in principle such a scheme would allow arbitrary extension whilst giving 
the user a very simple rule to prevent markup. "DO NOT WRITE '<<'".

But, as I've said before the real problem of creole is that:

THERE ARE TOO MANY PEOPLE IN THE CREOLE PROJECT WITH PRE-EXISTING 
ENTRENCHED POSITIONS WHO ARE UNWILLING TO SEE ANY MOVE TOWARD A COMMON 
STANDARD WHICH WOULD THREATEN THEIR OWN POSITION.

And if there were a small group of people who aren't in that position 
who would like to progress, then I would be willing to help out, but I'm 
not wasting time with a doomed project team who are the quintessential 
committee trying to design a horse that ten years after the user has 
died, ends up with a camel with wings!!!!

Or the committee that specified ChinookIII helicopters -- spent £500,000 
for 8 and then another £120,000 to downgrade the software to chinookII 
during which time the army had to go and buy other helicopeters to fight 
the Afghan war!

Mike


> If you want a very tight, restrictive spec. write it, write a parser,
> promote it, give "Kirk Compliant" badges to wikis that guarantee never
> to violate it.
> 
> And good luck to you. But you'll have to start your own movement,
> because I doubt WikiCreole is going to be it.
> 
> phil
> 
> 
> On Thu, Jun 5, 2008 at 8:48 AM, Mike Haseler <mike at lenzie.org.uk> wrote:
>>> Our plan was that Creole Additions would be used for things such as
>>> text color that not every wiki needs, but some wikis want.  The idea
>>> was that we would first standardize the elements that everyone needs
>>> and then the optional elements we would put in Additions.  Does this
>>> address that issue?
>>>
>>> We really did work hard to make this spec, and yes I'll admit it's
>>> quite lax, but we're open to criticism.  :)  I'm thinking we should
>>> mention Dirk's grammar on WikiCreole.org more prominently.
>>>
>>> Peace,
>>> Chuck
>>>
>> Chuck,
>>
>> I've no doubt you worked hard on the spec. I think what really made me angry
>> was the thought of all this effort - and badly needed effort - going to
>> waste through lack of ambition.
>>
>>> was that we would first standardize the elements that everyone needs
>> As a user, I'm beginning to realise that what I need the standard to say is
>> WHAT IS NOT GOING TO PRODUCE MARKUP. As a user, I'm prepared to find out how
>> to do things, but it really pisses me off to find things that I think should
>> be interpreted as text being interpreted as markup when:
>>
>> 1. I often don't know the application being used on the site
>> 2. Even if I knew the application, I probably don't know the markup it uses
>> 3. Even if I had experience of the application and markup, the huge variety
>> of markup and uses means I forget what does what on what site.
>>
>> I really need to have some simple rules to be able to predict which
>> character combinations **WILL NOT BE INTERPRETED AS FORMATTING**
>>
>> Every time some brightspark invents another sequence of characters, it is
>> another potential pitfall for anyone who is brave enough to post on unknown
>> sites.
>>
>> That is what I think was forgotten when Creole set as its goal being
>> "collision free" and "optional" or whatever it says.
>>
>> By saying you aren't going to have character sequences that are already used
>> elsewhere, you are effectively increasing the number of character
>> combinations that a user on a random wiki needs to avoid to prevent
>> inadvertent markup - you are making the task of wiki entry MORE DIFFICULT
>> NOT LESS.
>>
>> By saying Creole markup is arbitrarily extendible with random sequences of
>> new characters depending on the whim of the code writer, you are in effect
>> telling the user they can never be sure how to avoid markup.
>> __EVEN ON A SITE THAT SAYS IT USES CREOLE!!!!!!!!!!!!!!!!__
>>
>> So, let me propose as the prime user-centric goals which I think are key to
>> a successful wiki markup spec:-
>>
>> 1. Creole will make maximal reuse of currently used markup characters and
>> sequences (not necessarily for the same formatting)
>>
>> 2. Creole will define all potential character code sequences even when many
>> may not be implemented in the current (or any) specification.
>>
>> The problem Creole faces is that:
>>
>> Goal (1) is totally undermined by the Creole's current attempt to be
>> collision free.
>>
>> Goal (2) is totally undermined by this idea of creating a core set of markup
>> and leaving it up to the developer to arbitrarily define whatever extension
>> code they like.
>>
>> Mike
>>
>> _______________________________________________
>>
>> wiki-standards mailing list. wiki-standards at wikisym.org
>> http://www.wikisym.org/cgi-bin/mailman/listinfo/wiki-standards
>>
>> For the wiki-research, wiki-standards, wikisym-announce mailing lists,
>> please see:
>> http://www.wikisym.org/cgi-bin/mailman/listinfo
>>
> 
> 
> ------------------------------
> 
> _______________________________________________
> wiki-standards mailing list
> wiki-standards at wikisym.org
> http://www.wikisym.org/cgi-bin/mailman/listinfo/wiki-standards
> 
> 
> End of wiki-standards Digest, Vol 22, Issue 10
> **********************************************
>