Menu
▾
▴
phpwiki-talk
|
From: Reini U. <ru...@x-...> - 2004-02-27 04:46:37
|
See http://tikiwiki.org/tiki-index.php?page=RFCWiki hey! want to fix some wiki format conventions, which is based NOT in the Wiki's I used to know: c2, usemod, phpwiki, moinmoin to mention the biggest and oldest ones, though tiki is of course the biggest now in terms of features. Bold Text 2 Underscores "_" __text__ Centered Text 2 Colons ":" ::text:: Colored Text 2 Tildes "~" ~~blue:text~~ Italic Text 2 Single Quotes "'" ''text'' MonoSpaced Text -+text+- Underlined Text 3 Equals "=" ===text=== ~~red:This is text is Red~~ Example: -=~~red:::A Red Centered Title Bar:: ~~ =- Example: ˆ This is a Box ˆ. Example: ...page... Example: ((new page)) Example: NewPage Example: ))NotAWikiPage(( Example: ((New Page|Description of my new page)) Example: [http://tikiwiki.org/] Example: [mailto:so...@so...] Example: [http://tikiwiki.org/|The TikiWiki Site] by some guy from the fiji's. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: electron <ele...@mg...> - 2004-02-27 07:05:47
|
This seems fine by me, a standard could benefit everyone well. Below are =
my
thoughts:
---
2.2. Colored Text=20
Text can be any color you want it to be. Two Tildes (~) are used =
followed by
the name of a color and a Colon (:) to specify the start of the Colored
Text. Two additional Tildes (~) are used to end the Colored Text.=20
Example: ~~red:This is text is Red~~=20
Colored Text can also be specified using HTML colors. HTML colors use 3
pairs of Hex numbers; one for Red, Blue, & Green so that 00 00 00 would
produce white. The syntax is two Tildes (~) followed by the Pound (#)
character and the Hex Numbers with a Colon (:) followed by the text to =
be
colored. Two Tildes (~) mark the end of the Colored Text.=20
Example: ~~#ff00ff:This is text is the color Magenta ~~=20
Note: Not all Color Names are valid in all Browsers, so to be on the =
safe
side, it is usually best to use the HTML number by default.
---
Add Section 2.2.1 or an appendix where Wiki applications define red, =
blue,
green, etc. Wiki applications should not pass on these words to the =
browser,
only the #sequence. One has to think of international compatibility as =
not
everyone speaks English.
---
2.11. Page Breaks=20
Page breaks allow you to control the length of a page for easy reading. =
A
new page can be added anywhere but should start at the beginning of a =
line.
A page break uses 3 Periods (.), the keyword page and another 3 periods =
(.)=20
Example: ...page...
---
Suggestion: Use 3 underscores instead. (___) No need for any sort of
"Keywords" in Wiki. Wiki is supposed to be simple.
---
2.15. Non-parsed text=20
It may be needed in some instances to avoid wiki to interpret any text. =
The
use of (~np~) and (~/np~) can be used to enclose a non parsed text.=20
Example: ~np~ non parsed text ~/np~
---
Suggestion: Use 3 tildes instead (~~~). I see HTML leaking in there. :)
---
2.16. Tables=20
Tables can be rendered using the double bar separator (||) to mark the
begining and end of a table, the bar separator (|) to define cells =
limits
and carriage line return to define the end of the row.=20
Example:=20
||=20
::Color Name:: | :: Color HEX :: | :: - Colored Text - ::=20
AliceBlue| ::#F0F8FF:: | ~~#F0F8FF:Colored Text~~=20
AntiqueWhite| ::#FAEBD7:: | ~~#FAEBD7:Colored Text~~=20
||
---
Suggestion: Tables can be rendered using the triple bar separator (|||) =
to
mark the begining and end of a table, the bar separator (|) to define =
cells
limits and double bar (||) to define the end of the row.=20
Never rely on /n.
Example:=20
|||=20
::Color Name:: | :: Color HEX :: | :: - Colored Text - :: ||
AliceBlue| ::#F0F8FF:: | ~~#F0F8FF:Colored Text~~ ||
AntiqueWhite| ::#FAEBD7:: | ~~#FAEBD7:Colored Text~~ ||=20
|||
---
2.17. Images=20
Images can be used in text using a syntax similar to the HTML sysntax =
but
using ({) and (}) to enclose the image.=20
Example: {src=3Dhttp://tikiwiki.org/logo.png width=3D20 height=3D10 =
desc=3DLogo}=20
The application MUST check that the image is in fact an image and =
process it
accordingly.
---
Suggestion: {src|desc|height|width}
Example: {http://www.phpwiki.org/images/logo.png|Logo}
Example: {http://www.phpwiki.org/images/logo.png|Logo|10|20}
Simplify, Simplify.
---
2.18. Special Characters=20
Of course - any of the characters in the ASCII table can be added to a =
wiki
page by enclosing it's number within a pair of Tildies.=20
Example: ~169~
---
This should be expanded to include Unicode characters. My only =
suggestion
could be including ~U:450373~ . I don't have a better way.
---
2.22. Adding Hidden Details in Lists=20
An expandable area allows you to display the major items in your list by
default. Every item is still there, but it needs to be expanded to =
become
visible. An expandable area is created by adding a minus (-) character =
after
the star (*) characters.=20
Example:=20
*This is a Level 1 item.=20
*This Level 1 item has Hidden Details. Click the Plus [+] to open it.=20
**-This is a Level 2 item. Clicking the Minus [-] will close it.=20
**This Level 2 item did not need the minus character.=20
*Back to Level 1.=20
Expandable areas work with Bulleted and Numbered lists.=20
---
This can cause some really strange behaviors and puzzled users. ("Where =
did
my text go?!!") Possibly require the previous line has a +, such as:
Example:=20
*This is a Level 1 item.=20
*+This Level 1 item has Hidden Details. Click the Plus [+] to open it.=20
**-This is a Level 2 item. Clicking the Minus [-] will close it.=20
**This Level 2 item did not need the minus character.=20
*Back to Level 1.=20
Maybe that was an omission?
---
2.25. HTML=20
Any HTML syntax can be used but MUST not be rendered by default =
displaying
HTML as normal text unless the user or administrator authorize the =
rendering
of HTML syntax in the application. In that way any application is by =
default
exempt of any scripting, embedded object or HTML vulnerability.=20
HTML rendering is discouraged.=20
---
PhpWiki requires HTML to be Encapsulated, I suggest it in the RFC as =
well.
Example: [[<a href=3Dhttp://www.phpwiki.org>Hi!</a>]]
---
Section 3 XML Schema:
Here the RFC should include the schema for Wiki XML files. Content =
between
Wikis should be easily movable and dumps/revisions should have a =
standard
schema.
PhpWiki uses 3 different methods for database dumps. Ugly. Hopefully the
goal will be a dump from phpwiki could be imported with ease to another
wiki.
I intend to write a schema if none exists but not for a month or two.
Requires digging into more than one of my XML books. :)
Jason Potkanski
Potkanski System Services
Orland Park, IL 60462
E-mail: ele...@mg...
Comments in this email above this line are under the Creative Commons
License. Comments below are owned by their respective persons.
-----Original Message-----
From: php...@li...
[mailto:php...@li...] On Behalf Of Reini =
Urban
Sent: Thursday, February 26, 2004 10:44 PM
To: php...@li...
Subject: [Phpwiki-talk] Someone is proposing a Wiki RFC with strange =
syntax
See http://tikiwiki.org/tiki-index.php?page=3DRFCWiki
hey! want to fix some wiki format conventions, which is based NOT in the =
Wiki's I used to know: c2, usemod, phpwiki, moinmoin to mention the=20
biggest and oldest ones, though tiki is of course the biggest now in=20
terms of features.
Bold Text 2 Underscores "_" __text__
Centered Text 2 Colons ":" ::text::
Colored Text 2 Tildes "~" ~~blue:text~~
Italic Text 2 Single Quotes "'" ''text''
MonoSpaced Text -+text+-
Underlined Text 3 Equals "=3D" =3D=3D=3Dtext=3D=3D=3D
~~red:This is text is Red~~
Example: -=3D~~red:::A Red Centered Title Bar:: ~~ =3D-
Example: ^ This is a Box ^.
Example: ...page...
Example: ((new page))
Example: NewPage
Example: ))NotAWikiPage((
Example: ((New Page|Description of my new page))
Example: [http://tikiwiki.org/]
Example: [mailto:so...@so...]
Example: [http://tikiwiki.org/|The TikiWiki Site]
by some guy from the fiji's.
--=20
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
|
|
From: Reini U. <ru...@x-...> - 2004-02-27 08:42:27
|
electron schrieb: > This seems fine by me, a standard could benefit everyone well. Below are my > thoughts: > Section 3 XML Schema: > > Here the RFC should include the schema for Wiki XML files. Content between > Wikis should be easily movable and dumps/revisions should have a standard > schema. Standard for whom? There is no common wiki standard yet. If people will decide on a standard one could switch from engine to engine, and only the wiki's with the best features will survive. That's far too liberal for me. Most new engines nowadays only survive because of their "weird" new syntax and their usebase hooked to that, and not because of their features. I don't like concentration that much. > PhpWiki uses 3 different methods for database dumps. Ugly. Hopefully the > goal will be a dump from phpwiki could be imported with ease to another > wiki. Not ugly. We have to support the old schema's also. The new MIME-ified syntax is the easiest, best and most general for us. XML is pure hype with no substance and generally overkill for such simple data as wiki formated text, which is just plaintext like =pod with headers. We have no loops, and almost no recursive structures in wikitext. Only our new blockformatter is moderately recursive, but other wikis are not that clever, so it's generally not mapable. Personally I prefer to do the translation on purpose in one of my favorite languages (lisp or perl or php) with a couple of lines, such as MoinMoin => PhpWiki, but if someone ever will come up with a unified wiki schema, we might have to think of supporting this new out- and input format also. Hopefully its no XML. This RFC format for example looks fine for such an intermediate format, because it's easy to read and easy to write. As any Wiki syntax, in contrast to XML as we all know. That's the whole reason why we use wiki or pod, and not HTML or troff. > I intend to write a schema if none exists but not for a month or two. > Requires digging into more than one of my XML books. :) Please do so :) I'd like to see such a thing in existance. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: electron <ele...@mg...> - 2004-02-27 13:07:00
|
electron schrieb: > This seems fine by me, a standard could benefit everyone well. Below = are my > thoughts: Standard for whom? There is no common wiki standard yet. If people will=20 decide on a standard one could switch from engine to engine, and only=20 the wiki's with the best features will survive. That's far too liberal=20 for me. Most new engines nowadays only survive because of their "weird"=20 new syntax and their usebase hooked to that, and not because of their=20 features. I don't like concentration that much. --- Before we get too far off base, are you for or against the RFC? I'm = going to guess we are both on the same page as for it, if not what should it be? --- > PhpWiki uses 3 different methods for database dumps. Ugly. Hopefully = the > goal will be a dump from phpwiki could be imported with ease to = another > wiki. Not ugly. We have to support the old schema's also. The new MIME-ified syntax is the easiest, best and most general for us. XML is pure hype with no substance and generally overkill for such=20 simple data as wiki formated text, which is just plaintext like =3Dpod=20 with headers. We have no loops, and almost no recursive structures in wikitext. Only our new blockformatter is moderately recursive, but other wikis are = not that clever, so it's generally not mapable. --- Ugly I say, in jest. When I first picked up PhpWiki I thought the MIME solution was very creative.=20 I'm not an XML fan, I'm a standards fan. Implementing XML is a pain and overkill and a bunch of swearing. The point and strength on XML is it is = a way to export data that non-similar databases can read. If you don't do = a good job implementing HTML, the browser can compensate. If you don't do = a good job in XML, the parser kicks out a strict error. XML just makes = sure everyone is on the same page and doesn't have to deal with silly-implementation-things(TM). Like the crap we have to go through for pear/adodb. --- Personally I prefer to do the translation on purpose in one of my=20 favorite languages (lisp or perl or php) with a couple of lines, such as = MoinMoin =3D> PhpWiki, but if someone ever will come up with a unified=20 wiki schema, we might have to think of supporting this new out- and=20 input format also. Hopefully its no XML. This RFC format for example looks fine for such an intermediate format,=20 because it's easy to read and easy to write. As any Wiki syntax, in=20 contrast to XML as we all know. That's the whole reason why we use wiki or pod, and not HTML or troff. > I intend to write a schema if none exists but not for a month or two. > Requires digging into more than one of my XML books. :) Please do so :) I'd like to see such a thing in existance. --- The XML schema is only for exporting/storage, not meant to be seen by = the end user or even what we store in our databases. (Unless one is really = nuts and has a ton of drive space.) Only to be included for engine = portability. And on a final note: Nonprogrammers <3 wiki. Programmers who know what $_ is <3 wiki too. -Jtp |
|
From: Reini U. <ru...@x-...> - 2004-02-27 13:44:18
|
electron schrieb: >>This seems fine by me, a standard could benefit everyone well. Below are > > Standard for whom? There is no common wiki standard yet. If people will > decide on a standard one could switch from engine to engine, and only > the wiki's with the best features will survive. That's far too liberal > for me. Most new engines nowadays only survive because of their "weird" > new syntax and their usebase hooked to that, and not because of their > features. I don't like concentration that much. > > Before we get too far off base, are you for or against the RFC? I'm going to > guess we are both on the same page as for it, if not what should it be? I'm strongly against this RFC, because I see only completely new inventions for wiki syntax. If so, then please a least common denominator of the most used wikis. And in a less stronger opinion I'm against standardization of wiki syntax also. we already so many different wiki formats, which reminds me on lisp in the 80'ies or scheme on the 90'ies. if a standard will come the small ones will die, because the features will then be more important. this happened to lisp with a complicated standard and scheme not with a super simple standard. that's why we have 300 different scheme implementations and 5 in lisp. (and only 3 of them strict ansi) > The XML schema is only for exporting/storage, not meant to be seen by the > end user or even what we store in our databases. (Unless one is really nuts > and has a ton of drive space.) Only to be included for engine portability. I know I know. Another overly bloated XML parsing class just to please some standard. And which will never be supported by the smaller wiki's, where you will need it. At least it must be loaded only on demand :) |
|
From: Bob A. <apt...@cy...> - 2004-02-27 15:31:25
|
Hi, On Fri, 27 Feb 2004 14:41:48 +0100 Reini Urban <ru...@x-...> wrote: > electron schrieb: > >>This seems fine by me, a standard could benefit everyone well. Below are > > > > Standard for whom? There is no common wiki standard yet. If people will > > decide on a standard one could switch from engine to engine, and only > > the wiki's with the best features will survive. That's far too liberal > > for me. Most new engines nowadays only survive because of their "weird" > > new syntax and their usebase hooked to that, and not because of their > > features. I don't like concentration that much. > > > > Before we get too far off base, are you for or against the RFC? I'm going to > > guess we are both on the same page as for it, if not what should it be? > > I'm strongly against this RFC, because I see only completely new > inventions for wiki syntax. If so, then please a least common > denominator of the most used wikis. You'd think that an RFC would cover the most common cases in current use so there'd be more chance of adoption by existing projects (especially since Microsoft isn't involved...) Kinda stupid to spec out new, incompatible syntax when there's already substantial overlap between the various implementations. > And in a less stronger opinion I'm against standardization of wiki > syntax also. we already so many different wiki formats, which reminds me > on lisp in the 80'ies or scheme on the 90'ies. if a standard will come > the small ones will die, because the features will then be more > important. You say this as if it's a bad thing. Here's my perspective as a user/admin of open code. Like commercial code, sometimes projects wither and die. For a few months I worried that phpwiki was no longer actively maintained or developed and I was very concerned about extracting and converting the substantial amount of wiki content that I have to another wiki. The worst thing that can happen to a wiki maintainer is losing the content; having the content 'trapped' in a proprietary format is possibly worse than just having it deleted because you still hold out some hope that you can get it back. A well-written standard would be a good thing so content can easily transferred from one wiki to another. Wiki authors can use whatever bizarre syntax suits them, as long as they can import and export the content in a standard format. > this happened to lisp with a complicated standard and scheme > not with a super simple standard. that's why we have 300 different > scheme implementations and 5 in lisp. (and only 3 of them strict ansi) Why do we *want* 300 different scheme implementations? Think of it like SQL and the weakness of the SQL standard: do we really want to have to write SQL-for-Oracle, SQL-for-Sybase, SQL-for-Postgres, SQL-for-MySQL, etc., etc.? What a waste of effort! > > The XML schema is only for exporting/storage, not meant to be seen by the > > end user or even what we store in our databases. (Unless one is really nuts > > and has a ton of drive space.) Only to be included for engine portability. > > I know I know. Another overly bloated XML parsing class just to please > some standard. ...and people who value their content and don't want to risk it being trapped in code that no longer meets their needs. > And which will never be supported by the smaller wiki's, where you will > need it. That's what an open set of standards-based libraries are for. Nobody can force a developer to use them but if the standard is sane and everyone else is using them, there's strong pressure to do so otherwise the project will be (justifiably) marginalized. I haven't looked at the draft in detail so I can't comment on specifics (looks like they're just coding up Tiki syntax as the One True Way. Bad idea.) I will say that there's a definite benefit to users in having a standard simple data interchange format. -- Bob |
|
From: electron <ele...@mg...> - 2004-02-27 15:58:07
|
On Fri, 27 Feb 2004 14:41:48 +0100 Reini Urban <ru...@x-...> wrote: > electron schrieb: > >>This seems fine by me, a standard could benefit everyone well. Below = are > > > > Standard for whom? There is no common wiki standard yet. If people = will=20 > > decide on a standard one could switch from engine to engine, and = only=20 > > the wiki's with the best features will survive. That's far too = liberal=20 > > for me. Most new engines nowadays only survive because of their = "weird"=20 > > new syntax and their usebase hooked to that, and not because of = their=20 > > features. I don't like concentration that much. > >=20 > > Before we get too far off base, are you for or against the RFC? I'm going to > > guess we are both on the same page as for it, if not what should it = be? >=20 > I'm strongly against this RFC, because I see only completely new=20 > inventions for wiki syntax. If so, then please a least common=20 > denominator of the most used wikis. You'd think that an RFC would cover the most common cases in current use so there'd be more chance of adoption by existing projects (especially since Microsoft isn't involved...) Kinda stupid to spec out new, incompatible syntax when there's already substantial overlap between the various implementations. --- Rurban knows common syntax a lot better than I do. RFCs, request for comments, need commenting on. Especially if you think it sucks. The = worst thing that can happen is it gets published as-is, and then you have = users claiming your software is non-standard, creating a mess you now have to implement and support. Especially if Tiki wants to claim standard. --- > And in a less stronger opinion I'm against standardization of wiki=20 > syntax also. we already so many different wiki formats, which reminds = me=20 > on lisp in the 80'ies or scheme on the 90'ies. if a standard will come = > the small ones will die, because the features will then be more=20 > important. You say this as if it's a bad thing. Here's my perspective as a user/admin of open code. Like commercial code, sometimes projects wither and die. For a few months I worried that phpwiki was no longer actively maintained or developed and I was very concerned about extracting and converting the substantial amount of wiki content that I have to another wiki. The worst thing that can happen to a wiki maintainer is losing the content; having the content 'trapped' in a proprietary format is possibly worse than just having it deleted because you still hold out some hope that you can get it back. A well-written standard would be a good thing so content can easily transferred from one wiki to another. Wiki authors can use whatever bizarre syntax suits them, as long as they can import and export the content in a standard format. > this happened to lisp with a complicated standard and scheme=20 > not with a super simple standard. that's why we have 300 different=20 > scheme implementations and 5 in lisp. (and only 3 of them strict ansi) Why do we *want* 300 different scheme implementations? Think of it like SQL and the weakness of the SQL standard: do we really want to have to write SQL-for-Oracle, SQL-for-Sybase, SQL-for-Postgres, SQL-for-MySQL, etc., etc.? What a waste of effort! > > The XML schema is only for exporting/storage, not meant to be seen = by the > > end user or even what we store in our databases. (Unless one is = really nuts > > and has a ton of drive space.) Only to be included for engine portability. >=20 > I know I know. Another overly bloated XML parsing class just to please = > some standard. ...and people who value their content and don't want to risk it being trapped in code that no longer meets their needs. > And which will never be supported by the smaller wiki's, where you = will > need it. That's what an open set of standards-based libraries are for. Nobody can force a developer to use them but if the standard is sane and everyone else is using them, there's strong pressure to do so otherwise the project will be (justifiably) marginalized. I haven't looked at the draft in detail so I can't comment on specifics (looks like they're just coding up Tiki syntax as the One True Way. Bad idea.) I will say that there's a definite benefit to users in having a standard simple data interchange format. -- Bob --- Besides saying I agree, I feel it's a waste to spend time on coding something that's already implemented. Extensibility is a good thing. -Jtp |
|
From: Reini U. <ru...@x-...> - 2004-02-27 15:45:58
|
Okay, Next PhpWiki project proposal: Convert other Wiki Formats to ours. Could happen that other wiki's will not be maintained anymore. And if there's such a converter class, we could also convert our format to others. So we can get rid of XML. Jeff's Inline/BlockParser framework comes quite handy for such a job. But at first I'll finish the more important goals. :) Bob Apthorpe: ... > The worst thing that can happen to a wiki maintainer is losing the > content; having the content 'trapped' in a proprietary format is > possibly worse than just having it deleted because you still hold out > some hope that you can get it back. > > A well-written standard would be a good thing so content can easily > transferred from one wiki to another. Wiki authors can use whatever > bizarre syntax suits them, as long as they can import and export the > content in a standard format. ... |
|
From: Bob A. <apt...@cy...> - 2004-02-27 16:06:02
|
On Fri, 27 Feb 2004 16:43:24 +0100 Reini Urban <ru...@x-...> wrote: > Okay, > Next PhpWiki project proposal: > Convert other Wiki Formats to ours. > Could happen that other wiki's will not be maintained anymore. > > And if there's such a converter class, we could also convert our > format to others. So we can get rid of XML. > Jeff's Inline/BlockParser framework comes quite handy for such > a job. > > But at first I'll finish the more important goals. :) When I start writing you a paycheck, you can pay more attention to me ;) -- Bob |
|
From: Philippe C. <ch...@sy...> - 2004-02-27 12:13:40
|
electron wrote:
>This seems fine by me, a standard could benefit everyone well. Below are my
>thoughts:
>
>---
>
>2.2. Colored Text
>Text can be any color you want it to be. Two Tildes (~) are used followed by
>the name of a color and a Colon (:) to specify the start of the Colored
>Text. Two additional Tildes (~) are used to end the Colored Text.
>
>Example: ~~red:This is text is Red~~
>
>Colored Text can also be specified using HTML colors. HTML colors use 3
>pairs of Hex numbers; one for Red, Blue, & Green so that 00 00 00 would
>produce white. The syntax is two Tildes (~) followed by the Pound (#)
>character and the Hex Numbers with a Colon (:) followed by the text to be
>colored. Two Tildes (~) mark the end of the Colored Text.
>
>Example: ~~#ff00ff:This is text is the color Magenta ~~
>
>Note: Not all Color Names are valid in all Browsers, so to be on the safe
>side, it is usually best to use the HTML number by default.
>
>---
>
> Add Section 2.2.1 or an appendix where Wiki applications define red, blue,
>green, etc. Wiki applications should not pass on these words to the browser,
>only the #sequence. One has to think of international compatibility as not
>everyone speaks English.
>
>---
>
>2.11. Page Breaks
>Page breaks allow you to control the length of a page for easy reading. A
>new page can be added anywhere but should start at the beginning of a line.
>A page break uses 3 Periods (.), the keyword page and another 3 periods (.)
>
>Example: ...page...
>
>---
>
>Suggestion: Use 3 underscores instead. (___) No need for any sort of
>"Keywords" in Wiki. Wiki is supposed to be simple.
>
>
Good idea I think. "page" is only francophone and anglophone AFAIK.
>---
>
>2.15. Non-parsed text
>It may be needed in some instances to avoid wiki to interpret any text. The
>use of (~np~) and (~/np~) can be used to enclose a non parsed text.
>
>Example: ~np~ non parsed text ~/np~
>
>---
>
>Suggestion: Use 3 tildes instead (~~~). I see HTML leaking in there. :)
>
>
>
Seems better, rendering of ~~~ in tutorials would be done with special
characters instead but that's a very minor disadvantage. TikiWiki would
currently need a bit of hacking for this change when plugins are embedded.
>---
>
>2.16. Tables
>Tables can be rendered using the double bar separator (||) to mark the
>begining and end of a table, the bar separator (|) to define cells limits
>and carriage line return to define the end of the row.
>
>Example:
>||
>::Color Name:: | :: Color HEX :: | :: - Colored Text - ::
>AliceBlue| ::#F0F8FF:: | ~~#F0F8FF:Colored Text~~
>AntiqueWhite| ::#FAEBD7:: | ~~#FAEBD7:Colored Text~~
>||
>
>---
>
>Suggestion: Tables can be rendered using the triple bar separator (|||) to
>mark the begining and end of a table, the bar separator (|) to define cells
>limits and double bar (||) to define the end of the row.
>
>Never rely on /n.
>
>Example:
>|||
>::Color Name:: | :: Color HEX :: | :: - Colored Text - :: ||
>AliceBlue| ::#F0F8FF:: | ~~#F0F8FF:Colored Text~~ ||
>AntiqueWhite| ::#FAEBD7:: | ~~#FAEBD7:Colored Text~~ ||
>|||
>
>---
>
>2.17. Images
>Images can be used in text using a syntax similar to the HTML sysntax but
>using ({) and (}) to enclose the image.
>
>Example: {src=http://tikiwiki.org/logo.png width=20 height=10 desc=Logo}
>
>The application MUST check that the image is in fact an image and process it
>accordingly.
>
>---
>
>Suggestion: {src|desc|height|width}
>
>Example: {http://www.phpwiki.org/images/logo.png|Logo}
>Example: {http://www.phpwiki.org/images/logo.png|Logo|10|20}
>
>Simplify, Simplify.
>
>---
>2.18. Special Characters
>Of course - any of the characters in the ASCII table can be added to a wiki
>page by enclosing it's number within a pair of Tildies.
>
>Example: ~169~
>
>---
>
>This should be expanded to include Unicode characters. My only suggestion
>could be including ~U:450373~ . I don't have a better way.
>
>---
>
>2.22. Adding Hidden Details in Lists
>An expandable area allows you to display the major items in your list by
>default. Every item is still there, but it needs to be expanded to become
>visible. An expandable area is created by adding a minus (-) character after
>the star (*) characters.
>
>Example:
>*This is a Level 1 item.
>*This Level 1 item has Hidden Details. Click the Plus [+] to open it.
>**-This is a Level 2 item. Clicking the Minus [-] will close it.
>**This Level 2 item did not need the minus character.
>*Back to Level 1.
>
>Expandable areas work with Bulleted and Numbered lists.
>
>---
>
>This can cause some really strange behaviors and puzzled users. ("Where did
>my text go?!!") Possibly require the previous line has a +, such as:
>
>Example:
>*This is a Level 1 item.
>*+This Level 1 item has Hidden Details. Click the Plus [+] to open it.
>**-This is a Level 2 item. Clicking the Minus [-] will close it.
>**This Level 2 item did not need the minus character.
>*Back to Level 1.
>
>Maybe that was an omission?
>
>
>
I don't really understand the objection, as why is *+ on second line?
Obviously users can be puzzled a bit at first time. We use it (and also
for titles) in TikiWiki documentation though, and it's pretty useful.
>---
>
>2.25. HTML
>Any HTML syntax can be used but MUST not be rendered by default displaying
>HTML as normal text unless the user or administrator authorize the rendering
>of HTML syntax in the application. In that way any application is by default
>exempt of any scripting, embedded object or HTML vulnerability.
>HTML rendering is discouraged.
>
>---
>
>PhpWiki requires HTML to be Encapsulated, I suggest it in the RFC as well.
>
>Example: [[<a href=http://www.phpwiki.org>Hi!</a>]]
>
>---
>
>Section 3 XML Schema:
>
>Here the RFC should include the schema for Wiki XML files. Content between
>Wikis should be easily movable and dumps/revisions should have a standard
>schema.
>
>PhpWiki uses 3 different methods for database dumps. Ugly. Hopefully the
>goal will be a dump from phpwiki could be imported with ease to another
>wiki.
>
>I intend to write a schema if none exists but not for a month or two.
>Requires digging into more than one of my XML books. :)
>
>
>Jason Potkanski
>Potkanski System Services
>Orland Park, IL 60462
>
>E-mail: ele...@mg...
>
>
>Comments in this email above this line are under the Creative Commons
>License. Comments below are owned by their respective persons.
>
>
>
>
>
>-----Original Message-----
>From: php...@li...
>[mailto:php...@li...] On Behalf Of Reini Urban
>Sent: Thursday, February 26, 2004 10:44 PM
>To: php...@li...
>Subject: [Phpwiki-talk] Someone is proposing a Wiki RFC with strange syntax
>
>See http://tikiwiki.org/tiki-index.php?page=RFCWiki
>
>hey! want to fix some wiki format conventions, which is based NOT in the
>Wiki's I used to know: c2, usemod, phpwiki, moinmoin to mention the
>biggest and oldest ones, though tiki is of course the biggest now in
>terms of features.
>
>Bold Text 2 Underscores "_" __text__
>Centered Text 2 Colons ":" ::text::
>Colored Text 2 Tildes "~" ~~blue:text~~
>Italic Text 2 Single Quotes "'" ''text''
>MonoSpaced Text -+text+-
>Underlined Text 3 Equals "=" ===text===
>
>~~red:This is text is Red~~
>Example: -=~~red:::A Red Centered Title Bar:: ~~ =-
>Example: ^ This is a Box ^.
>Example: ...page...
>
>Example: ((new page))
>Example: NewPage
>Example: ))NotAWikiPage((
>Example: ((New Page|Description of my new page))
>Example: [http://tikiwiki.org/]
>Example: [mailto:so...@so...]
>Example: [http://tikiwiki.org/|The TikiWiki Site]
>
>by some guy from the fiji's.
>
>
I'm posting this to Tiki devel-list.
A comment on syntax I already received from a Tiki admin was that using
__ for bold instead of underlining (currently ===) was strange. This
makes sense to me at first glance. Luis Argerich first implemented that
syntax, I think it would be interesting to get his comments on those
changes.
Philippe Cloutier
|
|
From: Franck M. <fr...@so...> - 2004-02-27 20:57:50
Attachments:
signature.asc
|
All these changes seem fine by me... Please use the comments area on the page, to record your comments regarding the syntax. http://tikiwiki.org/tiki-index.php?page=RFCWiki I think we are not worried if the syntax breaks the current tiki, as the tiki group is looking for establishing a Wiki API. We will try to ensure we can implement the new syntax while providing backward compatibility. I suggest Philippe Cloutier wrote: > electron wrote: > > >> >> >> 2.22. Adding Hidden Details in Lists An expandable area allows you to >> display the major items in your list by >> default. Every item is still there, but it needs to be expanded to >> become >> visible. An expandable area is created by adding a minus (-) >> character after >> the star (*) characters. >> Example: *This is a Level 1 item. *This Level 1 item has Hidden >> Details. Click the Plus [+] to open it. **-This is a Level 2 item. >> Clicking the Minus [-] will close it. **This Level 2 item did not >> need the minus character. *Back to Level 1. >> Expandable areas work with Bulleted and Numbered lists. >> --- >> >> This can cause some really strange behaviors and puzzled users. >> ("Where did >> my text go?!!") Possibly require the previous line has a +, such as: >> >> Example: *This is a Level 1 item. *+This Level 1 item has Hidden >> Details. Click the Plus [+] to open it. **-This is a Level 2 item. >> Clicking the Minus [-] will close it. **This Level 2 item did not >> need the minus character. *Back to Level 1. >> Maybe that was an omission? >> >> >> > I don't really understand the objection, as why is *+ on second line? > Obviously users can be puzzled a bit at first time. We use it (and > also for titles) in TikiWiki documentation though, and it's pretty > useful. > I think it is an omission.... >> > I'm posting this to Tiki devel-list. > A comment on syntax I already received from a Tiki admin was that > using __ for bold instead of underlining (currently ===) was strange. > This makes sense to me at first glance. Luis Argerich first > implemented that syntax, I think it would be interesting to get his > comments on those changes. > > Philippe Cloutier I suggest **bold** This is used in e-mails a lot... __underlining__ This one does not provide backward compaqtibility but seems more logical About XML, my idea is that if an application needs to differentiate from a plain text document to a wiki document, then the word wiki must be start on the first character of the first line. No others words are permitted on the line... In a wiki application this feature is unlikely to be used, but in an e-mail document it could be useful... I don't think wiki documents should have a version number. Cheers -- Franck Martin ICT Specialist fr...@so... SOPAC, Fiji GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320 "Toute connaissance est une reponse a une question" G.Bachelard |
|
From: Whit B. <wh...@tr...> - 2004-02-27 21:20:59
|
On Sat, Feb 28, 2004 at 08:54:50AM +1200, Franck Martin wrote: > > I suggest > > **bold** This is used in e-mails a lot... > > __underlining__ This one does not provide backward compatibility but > seems more logical What seems logical will depend on where the user is coming from. Back when manuscripts were prepared by typewriters, which didn't have italics of course, the _ character when used to underline meant 'italics'. In normal printed English there is no use of underlining; italics and bold are pretty much it, aside from type size. And nobody wants to type more complexly in a wiki than they have to. So what's the logic of not doing *bold*, _italics_, _*bold italics*_ and perhaps __underlining__, ___underlined italics___, __*underlined bold*__, ___*underlined bold italics*___ - since that means the most typing for the least-used effects. Just my two cents. Hopefully many of the implementations will allow these to be configured locally (with export options of course).... Whit |
|
From: Reini U. <ru...@x-...> - 2004-02-29 03:16:17
|
Feel free to add comments: http://phpwiki.sourceforge.net/phpwiki/WikiRFC -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Franck M. <fr...@so...> - 2004-02-29 21:46:47
Attachments:
signature.asc
|
Please note, that I have not yet submitted the syntax to IETF, but told them I was working on it and wanted to submit it. Before even a submission is adopted it will go to many review processes. Submitting a draft means that the process is now starting and open for comments. It may take time to reach RFC Standard level. I thought that there was some wiki people on IETF, but it seems I'm the only one there, so I contact this group to share at least experience between two wiki syntaxes... I'm adding some coments... Cheers Reini Urban wrote: > Feel free to add comments: > http://phpwiki.sourceforge.net/phpwiki/WikiRFC -- Franck Martin ICT Specialist fr...@so... SOPAC, Fiji GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320 "Toute connaissance est une reponse a une question" G.Bachelard |
|
From: Franck M. <fr...@so...> - 2004-02-29 22:47:13
Attachments:
signature.asc
|
Please read: http://www.ietf.org/rfc/rfc2026.txt It describes how an Internet Draft becomes eventually a standard, but it is a long winding road... As the document below is misleading in many parts. I will write some modifications (as per suggestions) in the current Internet Draft (it has not yet been submitted), but I'm happy it is generating a lot of Interest and reactions (sometime you need to shake the tree). Please be mindful that at one stage we will all have to modify our various wiki engines to be compliant with a base standard... But this is not for now... I will take the first round of suggestions I got, then submit to the IETF as Internet Draft version 1 and we will all have now a reference to make something better. Cheers Reini Urban wrote: > Feel free to add comments: > http://phpwiki.sourceforge.net/phpwiki/WikiRFC -- Franck Martin ICT Specialist fr...@so... SOPAC, Fiji GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320 "Toute connaissance est une reponse a une question" G.Bachelard |
|
From: Franck M. <fr...@so...> - 2004-02-29 23:18:27
Attachments:
signature.asc
|
http://www1.ietf.org/mail-archive/ietf/Current/msg24012.html It all started by this message, for info... Reini Urban wrote: > Feel free to add comments: > http://phpwiki.sourceforge.net/phpwiki/WikiRFC -- Franck Martin ICT Specialist fr...@so... SOPAC, Fiji GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320 "Toute connaissance est une reponse a une question" G.Bachelard |
|
From: Reini U. <ru...@x-...> - 2004-02-27 13:57:44
|
Olivier Fambon schrieb: > http://textism.com/tools/textile/index.html > http://textism.com/ > > Don't really know if this is just minor dandy stuff... if this would be javascript it would be cool. as cgi it is dandy. I already saw such javascript formatters, which would come handy to paste from word or html, and let it strip the wrong chars and do some major conversion and formatting very fast. even some kind of mini wiki in jscript. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X