(anonymous guest) (logged out)

Copyright (C) by the contributors. Some rights reserved, license BY-SA.

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 
This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

I think we need to separate this thing into several layers, otherwise we are confusing thigs. Of course, there is no such thing as a division between "presentation" and "content". Presentation is content, no matter what artifical or technical boundaries we set. The style sheets, semantic markup and other techniques of separating "content" from presentation "work" simply because some of the content is repetitive, easily abstracted and defined globally for the whole site, and some of it is very specific to certain page or place on the page. Separating the repetitive part saves us work. While designing an inter-site language like Creole, we encounter yet another layer -- things that are common not only for all pages on a site, but also for all the sites. Actually this is the part that we are trying to define. The split between "semantics" and "contents" is purely practical.

Obviously, different wiki sites have very different look and behave in different ways -- hopefully reflecting the needs of associated community of users. The http://senseis.xmp.net/ wiki coudn't function the way it does without a markup of describing joseki. A wiki dedicated to mathematics needs some way to enter and refer to mathematical formulas. A wiki focusing on ascii-art coudn't function without a way to make <pre> blocks. A wiki dedicated to discussions about HTML or web development might benefit greatly if there was a way to enter raw HTML. And so on, there can be countless examples.

Obviously, we don't want to define all the markup and corresponding presentation. On the contrary, we should try and define as little of it as possible while still meeting the Goals. Every rule, each restriction or definition, we introduce into Creole is going to conflict with some existing or future site out there, making it harder to meet the goal of creating a wiki-exchange language. We want to stay ExtensibleByOmission as much as possible.

One thing that we can skip most of the time is the exact presentation. This is very fortunate, as practically every wiki site out there uses a custom style sheet and defines its own look and feel -- any attempt to standarize them would meet a laughter from the direction of web designers. Even if we support our decissions with countless arguments from tradidtion, aesthetics and cognitive science -- they know better. Better stay out of their way.

Of course there is a second edge of this blade. If we define too little, then the language will be practically useless -- most of the code will be either specific to the wiki site on which it was created or distorted in interpretation beyond recognition (sure, seasoned typographers know that it's an old tradition to typeset foreign phrases with italics -- now go ask a random teenager).

Thus we need to balance things. Define enough to allow resue of raw text between wikis and contribution to wikis without knowing all of their markup -- but leave enough space for artistic creativity and subject-specific adjustments. Incidentally, most of what we need to reatain um... meaning between differently implemented Creole wiki is... the meaning of the markup in question. Of course, there are cases when the meaning is tied closely with the presentation -- and then we need to define the presentation too. In other cases though it's exactly the other way around -- keeping the presentation fixed would distort the meaning between different wikis.

Take for example the inline quotes. You could say: "there is so many ways of quoting -- using emphasis, using relative clauses (?), using dozens of different quotation glyphs -- better leave this to the discretion of the user". And then, on the same wiki page, we have Americans quoting 'like this' and `like this', Englishmen quoting "like this" and ``like this, Poles quoteing ,,like this, Frenchmen quoting >>like thisPlugin insertion failed: Could not find plugin GermansPlugin insertion failed: Could not find plugin Germans and Seasoned Typographers using intalics. Now start to copy-paste this text around between wiki sites inhabited by people of different nationalities, and suddenly what was two quotes for a Frenchman become a single quotation for a German. Poles get accused of missing parts of sentences between the commas, and Americans get lost in olde-style alliterations. And then the Universe implodes.

Another example -- let the users format their text manually, by inserting line breaks, indenting text, etc., but don't define a standarised page width. After several migrations, a text that looked like this on one wiki:

    Lorem ipsum dolor sit amet, consectetuer adipiscing elit, 
  sed diam nonummy nibh euismod tincidunt ut laoreet dolore
                                 magna aliquam erat volutpat. 
    Ut wisi enim ad minim veniam, quis nostrud exerci tation
  ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo
                                                   consequat.
will change dramatically on another one (not to mention another computer or, Holy Bill forbid, browser):
    Lorem ipsum dolor sit amet, consect
etuer adip iscing elit, 
  sed diam nonummy nibh euismod tincidu
nt ut laoreet dolore
                                 magna 
aliquam erat volutpat. 
    Ut wisi enim ad minim veniam, quis 
nostrud exerci tation
  ullamcorper suscipit lobortis nisl ut
 aliquip ex ea commodo
                                       
            consequat.

To sum up, there is no general rule telling whether Creole should be more "semantic" or more "presentational". Each and every case must be considered separately, and the decission will impact the adoption and usefulness of the markup language.

-- RadomirDopieralski, 2006-01-02

Add new attachment

Only authorized users are allowed to upload new attachments.

« This particular version was published on 02-Jan-2007 02:15 by RadomirDopieralski.