(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-108) was last changed on 24-Sep-2008 09:01 by 217.218.168.100  

This page was created on 03-May-2007 01:01 by 84.150.67.149

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 142 added 12 lines
I tried to write a grammar parser for the Creole 0.6 specification. Thus the specification is desired for regular expression based translation to HTML, I have some issues you might not consider and I hope it’s could be interesting for you. I mean if the 1.0 specification should be valid for two years, you could/should consider that some people want to use a scanner/parser created from a grammar. Why not, it offers much more potential for the future. Further you can offer a grammar instead of a prose specification. Wiki engine developer could easily use different scanner/parser generator for different target programming languages. \\
"The bold/italic text will end at the end of paragraphs, list items and table cells": This implies that closing bold/italic markup is optional in a grammar and this implies that the unacceptable {{{**//bolditalic**}}} cannot throw an error. I think a user who can handle an escape character that only escapes in front of an non-alphanumerical and non-whitespace character can close the markup or at least can see on the rendered page that something is wrong.\\
The leading spaces before list items are user-friendly, but imo not necessary, because you get an indentation by the number of asterisks/pounds. On the other hand, why isn’t it allowed before a heading? (This conflicts with usability.) Using a greater look-ahead for skipping the leading spaces decreases the performance of the parser and complicates the definition of a grammar.\\
Paragraphs: "A list, table or preformatted block end paragraphs too." I think it is mentioned that each list, table, preformatted block is its own paragraph, isn’t it? Btw, it would be much easier to parse if every time a blank line separates the paragraphs.\\
Independent from any implementation, an escape character should be context-free. I would expect this behavior and I think it's easier for a user to remember that there is an escape character and what it effects than giving a specification where it works and where not.\\
Annotations for publishing a clearer specification:\\
Lists: "Bold, italics, links, nowiki can be used in list items". Nowiki could be nowiki inline or nowiki block. Later this is called preformatted. It becomes more confusing as the monospaced occurs (in Tables). It would be easier to use a fixed nomenclature.
The example "* This is a single list item\\followed by a paragraph?" does not really fit to forced linebreaks. It should be in the Lists section to clarify the end of a list.
-- Martin Junghans, 2007-06-11
Version Date Modified Size Author Changes ... Change note
108 24-Sep-2008 09:01 47.251 kB 217.218.168.100 to previous
107 24-May-2008 21:26 47.247 kB 24.201.230.79 to previous | to last escape characacter in url answer
106 23-May-2008 19:53 46.839 kB 212.242.206.149 to previous | to last Escape characters in URLs considered bad
105 19-May-2008 14:58 46.067 kB StephenDay to previous | to last answer
104 18-May-2008 17:23 45.863 kB 89.242.167.236 to previous | to last Added discussion on TT tag
103 14-May-2008 08:30 45.52 kB BenKovitz to previous | to last Thanks for the clarification
102 13-May-2008 20:11 45.29 kB StephenDay to previous | to last answer
101 12-May-2008 22:45 45.05 kB BenKovitz to previous | to last Is the example with two opening braces correct?
« This page (revision-108) was last changed on 24-Sep-2008 09:01 by 217.218.168.100