Re: [cowiki-dev] Extension to coWiki text formatting

Archie Campbell wrote:

>
> I really don't know about the extent to which 'availability of 
> [sophisticated formatting] will be controlled by the site 
> administrator', but I would like to comment briefly on the proposed 
> markup, mostly the stuff that is already familiar.

This is a security feature that we'd need to add on the administration 
pages.  Basically the ability to turn the processing that enables these 
features on and off.

> Does coWiki attempt to save & redisplay? Certainly stuff that can't be 
> processed is often displayed in full, a sort of 'default to verbatim'. 
> If we can define parser-success, then we can fail-to-verbatim. What if 
> closing all tags was all we had to put faith in?

Presently coWiki will save text that it does not recognize as valid.  
dtg must have included a mechanism to make this happen because I see 
it.  What I'm proposing is to make the parser robust enough to detect 
when text is poorly formatted.  Since the text that the user submitted 
will still be available, it can be returned to the user for correction, 
along with hints about where the problem is.

> Doubled emphasis is a simple and effective solution. Nice one. I was 
> thinking of of forcing the position of emphasis markup, but doubled 
> emphasis with self-escaping covers everything.

Thanks.  Actually I've seen this solution on a couple of other wikis, so 
I can't take full credit.  ;-) 

> For argument's sake, a content-section begins where a new context is 
> defined, and lasts until the close of that context, commonly with a 
> newline.
>
> Headings should be recognised at the beginning of a content-section.
>
> Lists, horizontal rules, preformatted text, code boxes, postings, 
> quotes, similarly.
>
> Beginning-of-content markups are available inside tables & lists, for 
> example.
>
> Links & variables & may be found wherever emphasis or justification 
> may be, line break, subscript & superscript likewise.

ACK, I think...

> New elements...
>
> The <URL...> syntax should define the containing element for the 
> merged (included) document?

Yes, it's incomplete.  It was really an idea to parallel including an 
image into text but I wasn't sure what you'd need to know.  Sort of like 
displaying a page from another site in a frame...

> Image syntax as given doesn't reflect proposed wiki-ness of images. 
> Possibly as dtg works we will come to specify them as 
> coming-from-the-database, not by url.

Also needs work as you note.  Other wiki's have separate syntax for 
included images and objects.  coWiki currently has the "embed" plugin.  
I'd like to make it a recognized part of our language.

> Changes to table format...
>
> Since there are times when defined row-element and rigorous table 
> syntax is required, I move that ^-delimited tables should be offered 
> alongside <table>|-</table> syntax. Use as required.

No major issue with this.  The <table></table> syntax is non-standard 
and other wikis don't seem to need it.  I intentionally don't try to 
extend the capability of wiki-text to everything that could be done, in 
the name of simplicity and ease of use for beginners.  If you need a 
more sophisticated presentation, the tools have been provided by other 
means.

An important improvement though is the availability of justification 
tags.  These actually have two effects:  First it provides individual 
control of justification, which currently applies to all cells of the 
table when it is provided.  Secondly, it becomes a natural "poor man's 
quote" for newlines when used on the content of a cell.

I didn't cover it in the proposal, but I'd use the existing mechanism 
for spanning cells.

> LPIs...
>
> May be found at newline, also must be first element (provided by 
> initial parse if not submitted).

LPI's can occur anywhere.  This is necessary so that elements from one 
language can be included in another.  For example, to include a coWiki 
constant into an HTML page.  It has the same purpose as scripting in 
HTML and JSP.

> Only cowiki and html (pasted verbatim) a present. Awaiting security. 
> How do we secure raw php? Or is what is wanted more a syntax 
> highlighter like GeSHi?

ACK.  I don't see PHP or any other language as crucial at the moment.  I 
more wanted to demonstrate how they fit into the whole picture, to 
understand that language selection operates at a higher level than the 
current language selection.  (I think that's the key to making it simple 
to implement.)

---

On the issue of language security-- There are natural and self 
consistent extensions following these rules:

    * The ability to save pages with a language feature represented
      either by a group or can be assigned to groups by the site
      administrator.  (Only one of these is required, and representing a
      feature by a single group is probably both easier to implement and
      faster to execute.)
    * A user is given the ability to save pages which invoke a certain
      language feature by adding that langugage group to their group list.
    * A user will not be allowed to save a page that invokes a language
      feature they are not entitled to use. 
    * To prevent a "got-you" syndrome, a user should be prohibited or at
      least warned when they attempt to edit a page that uses a feature
      they are not entitled to.  (Maybe just warned because they may be
      removing the feature...)
    * Individual language features can be turned on and off by the site
      administrator.  If a feature is turned off, it cannot be parsed on
      a page when it is saved. 

All of this security intentionally pertains to pages when they are 
/saved/.  This lets previously saved pages, which invoke now disabled 
features, to continue to work without error.

Paul