[wiki-standards] Specification for markup specification
Dirk Riehle
dirk at riehle.org
Wed Jun 4 10:42:47 CEST 2008
Hi Mike, everyone:
As Janne already said, wikis are about communities, and so are
standards. There are no standards without community consensus :-) which
typically means that the community has somehow been involved. Chuck and
Chris did a great job in rallying the community around Creole. I doubt
they consider their work finished though, and some of the things you are
suggesting below are clearly next steps after the informal Creole
specification.
Being a computer scientist, I also feel that a prose description is just
a beginning. That's (one reason) why we developed the grammar.
Creole can go much further, and so we developed a fair amount of XML
technology around it, to improve portability, storage, independence.
First to be named is an XML-based representation of Creole as well as
XSLT scripts to convert the XML to Creole and vice versa (plus code).
You can reach it from the Creole wiki or directly here:
http://www.riehle.org/wiki-creole/
Other people are also developing Creole based parsers and you can find
some of those projects on SourceForge.net, just search for Creole.
Our work of course is just our work, not a standard. However, individual
person/group work is the first step to later community consensus. There
is some competition around the Wiki Creole parsers and renderers and
this will lead to a healthy "natural evolution" competition, I hope.
There is no competition that I'm aware of around our XML format/schema
and the XSLT scripts, and we are seeing a nice consistent level of
interest in this.
What I would love to see people pick up is to develop a true
(open-source) JavaScript (client-side) parser (Creole input to XML/JSON)
so that browser and server communicate using XML/JSON. We didn't do a
JSON spec for Creole but you can derive it from the XML spec easily
(you'd gain a consistent spec out of the box rather than having to find
out about some of the problems yourself). XML to XHTML is fairly trivial
and you can see how it works and have a prototype using our XSLT script
for that.
Cheers,
Dirk
PS: Is anyone stepping up to get us organized around this for WikiSym
2008 in September? Two years after the Creole workshop at WikiSym 2006
it might be about time...
Mike Haseler wrote:
>
>
> Intro
>
>
> I was trying to rationalise to myself why I so disliked the creole
> markup "wish-list" and I began noting down all the things I dislike
> about creole and using wikis, bulletin boards and other text input in
> general. The current status is really just a note to myself to help me
> work out what to do next in terms of which strategy for markup.
>
> "KIRK" still refers to my ambition to one day know how to enter "bodly
> go" in bold into any text application.
>
>
> Meta Aims
>
> 1. *Definitions*
> 1. *Display* refers to any mechanism whereby the words and
> characters of the text are conveyed to the user with the
> emphasis and added information given by the markup.
> 2. *The User* refers to anyone entering text with markup.
>
> 2. *No Markup Default. *The default for any kirk text shall be to
> display the text as unformatted characters and in particular:
> 1. Alphanumeric characters shall always have their normal
> meaning except in exceptional circumstances and only then
> in specific contexts.
> 2. Kirk shall clearly define in all contexts, the
> non-alphanumeric characters which retain their normal meaning.
> 3. The mechanisms to avoid text being interpreted as markup
> shall be many and obvious.
> 4. The conditions for causing text to be interpreted as
> markup shall be explicit and in any case of ambiguity the
> default shall be that the text is not interpreted as markup.
> 5. Formatting will cease if any condition occurs which a
> reasonable user would interpret as the end of formatting.
>
> 3. *Translatable. *It shall be possible to translate the kirk text
> to a form where text and formatting are independent so that any
> kirk page may be translated and displayed identically in this
> external formatting and then translated back such that no matter
> how many times this cycle is repeated, the final kirk page shall
> have an identical appearance to the user as any initial kirk page.
>
> 4. *No impossible text. *The specification of Kirk shall be such
> that any arbitrary page of ASCII (or other) text within the
> hypothetical external format, can be reproduced so as to appear
> to be the same characters as a whole page or as a part within
> any formatting section (with the exception of tabs where the
> formatting is controlled by external factors)
>
> 5. *Defined tokens. *Kirk formatting tokens shall consist of:
> 1. Whitespace: consisting of one or more spaces and/or tabs
> 2. Newlines (including all combinations of single linefeed
> and carriage return)
> 3. Two or more identical symbols
> 4. A newline followed by one or more identical symbols
> 5. Single characters or combinations not covered by the above
> but only within specific contexts (such as within tables
> or in formatting or division of parts within a hyperlink),
> with the sole exception of …
> 6. … the escape character whose action shall always be to
> cause the following single character to be interpreted as
> a none token character and to be displayed as is; except,
> where the escape character’s behaviour is explicitly
> defined and compatible with aims (2) and (3) .
> 7. Within specific contexts such as tables, tokens may signal
> specific behaviour as the first whitespace character after
> a newline or the last none whitespace character before a
> newline.
>
> 6. *Simple and Consistent Syntax.* Where elements follow a syntax,
> this must be simple and consistent between different elements.
> Where elements are identified by order, the order from left to
> right must follow:
> 1. The natural flow as the user sees it,
> 2. or the priority of the elements from highest to lowest as
> seen by the user.
>
> 7. *Intuition. *The tokens used in Kirk shall relate as closely as
> possible to the format that they produce.
>
> 8. *Extendible.* The kirk specification shall make provision for
> extension so that any text including any arbitrary extension
> shall be displayed by any application unable to interpret the
> extension in a consistent, predictable manner.
>
> **
> 9. *Declaration*. Applications should actively inform the user in a
> prominent way that they are Kirk compatible and provide details
> of any extensions to the standard.
>
> **
>
> *Help*. All kirk compatible applications must provide on each page
> where Kirk text is entered by the user a mechanism to provide help for
> the user with the details of the Kirk markup. *
>
> *
> ------------------------------------------------------------------------
>
> _______________________________________________
>
> 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
--
Into novel software paradigms, tools, processes?
Then submit a short paper to Onward! 2008 by July 2nd!
See http://www.oopsla.org/oopsla2008/cfp/cfp-onward.html
--
Phone: + 1 (650) 215 3459, Web: http://www.riehle.org
More information about the wiki-standards
mailing list