Wikitax (proposal)

From Meta, a Wikimedia project coordination wiki
(Redirected from Wikitax)
Jump to: navigation, search
Ambox outdated content.svg

This page is kept for historical interest. Its content is outdated or may be wrong.

You may find more up-to-date information on the www.mediawiki.org website.

MediaWiki logo
Blue Glass Arrow.svg MediaWiki logo.png
A proposal to move this page to MediaWiki.org was rejected.
Because the Template:MoveToMediaWiki tag was on the page for a year without any MediaWiki.org importers seeing fit to transwiki it, the move proposal was regarded as rejected by the MediaWiki.org community.

See also Wikitext syntax, Wiki markup syntax.

Remark: The following is a proposal for large changes in Wikimedia's markup. Just because it is stored in Wikipedia doesn't mean that it is supported by the community or that it will ever be used for Wikipedia. On Wikitext syntax it's said that it is unlikely that this proposal will ever be implemented.

We are undergoing the finalization and standardization of Wikitax, a rich markup targetted for use by laypeople in effectively contributing to next-generation Internet-based collaborative, community, and content management interfaces. This specification was originally drafted by Derek P. Moore in conjunction with his work on the next generation of codebases for w:Independent Media Centers. We're in a sort of request for comments stage with Wikitax right now. We all need to just brainstorm and tweak.

See simple ideology of Wikitax to wax philosophical on the broad issues of usability and simplicity.

The resulting ideas, dialog, discussion, and|or specification may influence the development of w:Software Phase IV.

If you wish to contribute to, comment on, or pose suggestions about the following draft specification, simply edit this page and break the text where you wish to comment with:

</nowiki></pre>
:Your comments, suggestions, ideas, contributions, critiques go here.
<pre><nowiki>

Or head over to Talk:Wikitax and discuss this page.

See also: http://www.piclab.com/cgi-bin/wiki.pl?Wikipedia_Text_Syntax

And so on with the fun:

#!/bin/sh
vim - <<END_of_Multiline_Text



Wikitax: a plaintext markup syntax to indicate semantical, display, and
         formatting information for text in CMSes, wikies, and blogs.

Text may also include much of HTML, etc., if users wish to use HTML instead of
the Wikitax equivalent. [?: what limits to impose, etc.]



Technical notation

  [wb] = word boundary
  [sp] = space

  X <<: Y
    strict set inclusion: X is included in Y, but not equal to Y
  X /<<: Y
    strict set non-inclusion: not(X <<: Y)



TODO (ideas that I need to flesh out more):
 * <big> and <small> [?: are equivalents to these necessary or desirable]
 * and other missing tags for text formatting [?: what am I missing]
 * aligned text and objects (maybe via some <div> or <span> equivalent)
 * headings <h1> .. <h6> ('-= h1 =-', '-=== h3 ===-', '-===== h5 =====-' [?])
   + headings also create an anchor of '#heading-name'
   + headings also create sections, which are closed with something similar to:
     '[[:end-section: "Ogg Vorbis"]]', assuming a heading of
     '-== Ogg Vorbis ==-'

I'd like to encourage consideration of a heading markup that is the same length for all heading levels, and explicitly includes the heading level. For example (building on my TWiki background): "---+1" for Level 1 thru "---+6" for Level 6. The reasons relate to my attempts to create (single heading) fold macros for editing TWiki files with Nedit, and the difficulty of doing that because Nedit RE's (at least) do not allow a variable multiplier. I.e., I'd like to do something like search for "---\+{1,a}?{?= }" inside a loop where a is decremented from 5 to 1 (along with some other processing). See [[1]] for a little more information and links to even more (I hope).</nowiki>
Software should follow the syntax not the other way round. But you can regexp wikitax into your syntax and vice versa, this should solve the problem.
I agree that I could convert between syntaxes, it's just extra steps that could be avoided. While "Software should follow the syntax not the other way round" might be (probably is) a reasonable rule of thumb under most circumstances, the request should be considered on its merits and the specific situation.

 * definition lists [?: what would the best syntax be]
 * cf. <http://www.wikipedia.org/wiki/Wikipedia%3AHow_does_one_edit_a_page>
 * cf. <http://docutils.sourceforge.net/rst.html>



-= Text formatting =-

The following table gives an overview of the [/basic/] text formatting features
of Wikitax:

  Syntax                                 Translation
  ------                                 -----------
  [*bold text*]                          <b>bold text</b>
  [/italicized text/]                    <i>italicized text</i>
  [=monospaced text=]                    <tt>monospaced text</tt>
  [_underlined text_]                    <u>underlined text</u>
  [-striked text-]                       <s>striked text</s>
  [+emphasized+]                         <em>emphasized</em>
  [++strongly emphasized++]              <strong>strongly emphasized</strong>
  [+++very strongly emphasized+++]       <em><strong>very strongly
                                           emphasized</strong></em>
  [^superscripted text^]                 <sup>superscripted text</sup>
  [,subscripted text,]                   <sub>subscripted text</sub>
  [%literal text, [/not evaluated/]%]    literal text, [/not evaluated/]

The various markups for text formatting can be applied in whatever combinations
you wish.  For example:

    [*[/bold and italicized/]*]
    [/[=italicized monospace ([-striked-])=]; not monospaced, still italicized/]
    [_underlined text with [^superscripted^] and [*bold*] words_]

Are there any combinations that should be explicitly defined as illegal?  Should
overlap like '[=monospaced, [/plus italics=], still italicized/]' be considered
legal and rendered into the target language properly, e.g., '<tt>monospaced,
<i>plus italics</i></tt><i>, still italicized</i>'?

The [bracketing] is very cumbersome. This needs to be seriously looked at. Why not just *bold* for bold? Bracketing should only be used for the below (i.e. to encompass blocks of multi-paragraph text). Also, monospaced text overrides h1. It should be something like: |monospaced|.
Moreover, what's wrong with the current '''bold'''? I like it. It's easy. And it combines well into '''''bold italics'''''.
Emphasis markers are obsolete. No one really uses the HTML emphasis over more direct bold and italics. --w:User:Alfakim
<nowiki>

-== Formatting in blocks ==-

Text can be formatted inline—as we've already seen—but we'd probably also run
into cases where it'd be helpful if the text could be formatted by blocks.  If a
line contains only markup codes, and no other text, the interpreter should know
to expect a block.  The block is closed by the corresponding closing tags being
on their own line at the end of a block.  For example,

    [*
    This paragraph.

    And this paragraph, too.
    Are bold.
    *]

Or, something that might be useful in the collaborative editing of documents,

    [/[-
    This block of text is italicized and striked because maybe it should be
    removed.

    There are several paragraphs o' junk here.  We're better off without it.
    -]/]

One of the inline markups that would function specially in block mode is the
monospace markup, [= ... =].  As this syntax provides for technical-looking text
inline, it sort of follows that in block mode it would provide for monospaced,
preformatted text—i.e., equivalent to <pre> ... 
. Markup inside a

preformatted block [*is*] evaluated.

For preformatted, literal (non-evaluated) text,

   [=[%
   All the text in this block is to appear /exactly/ as it does in plaintext,
   with no evaluation of markup, etc.  Ampersands, angle brackets, and other
   special characters should be translated into their character entities,
   though, so they're rendered properly in browsers.
This should behave like
 in Wikipedia markup.  [*All*] Wikitax
    markup within this block [/is not/] rendered.
    %]=]

Blocks of text might require other forms of formatting that don't occur on an
inline basis; e.g., indentation, etc.  For indentation, the following syntax is
proposed:

    [>
    This block of text is indented, similar to <blockquote>.
    <]

Possibly you want different levels of indention (on the left or right side of
justification), etc.  Other possibilities may be

    [>>
    This block is indented two levels, on both the left and right sides of the
    page.
    <<]

... Or ...

    [>>
    This block is indented two levels on the left, but one level on the right.
    <]

... Or ...

    [>>>
    This block is indented three levels on the left, but fully justified to the
    right.
    |]

... And things such as the following would prove useful:

    [|
    This block is fully justified on the left, but indented three levels on the
    right.
    <<<]

Can anybody think of any other block-mode-only formatting that might be
required?

Yes, two things:
[>> 
This text is indented two levels on the left, and inherits default right-hand formatting 
#]
...and...
[{ 
This text is contained within a left-floating div. 
{]

Question:  Would implementing markup attributes be too much?  E.g., what if you want to specify the width of a left-floating div?  

-Nathan
21:48, 14 December 2005 (UTC)

-= Wiki links =-

  Syntax                     Translation
  ------                     -----------
  [[Wiki Link]]              <a href="...?$1">$1</a>
                             <a href="...?Wiki_Link">Wiki Link</a>

  [[link->Wiki Link]]        <a href="...?$2">$1</a>
                             <a href="...?Wiki_Link">link</a>

Wiki links are a means of creating links to wiki-style content.  Text surrounded
in double square brackets, [[ ... ]], constitutes a wiki link.  For example, in
this sentence, the phrase [[Wiki Links]] is surrounded by square brackets.  In
your normal wiki-style setting, the phrase 'Wiki Links' in that sentence would
become linked to the article entitled 'Wiki Links'.  What I refer to as wiki
links in this document are sometimes referred to as 'free links'.  Say we wanted
to create a wiki link that points to the 'Wiki Links' article, but we want the
text of the link to read 'free links'.  This is illustrated in the following
sentence:  Wiki Links are sometimes referred to as [[free links->Wiki Links]].

The [[ ... -> ... ]] syntax is perfect for some situations, but far too verbose
in others.  Say we are talking about governments, and we want the word
'governments' to point to the article on 'government'.  In cases similar to
this, it's quite ridiculous to write '[[governments->government]]', when
'[[government]]s' is much more concise and straight-forward.  This suffix syntax
for Wiki Links is often quite useful, as you can imagine.  Suffix syntax should
also work with other popular suffixes, e.g., -ing, [[cater]]ing; -ed,
[[retard]]ed; -'d, [[GPL]]'d; -'s, [[Derek P. Moore]]'s; -s', [[people]]s'; -',
[[General Motors]]'; -es, [[wiki]]es; -es', [[wiki]]es'; etc.

The possessive noun suffix, -', might conflict with times when you want to
surround a wiki link in single quotes, e.g., '[[quote]]'.  Having the parser
figure out when a single quote is the end of a quote or alone may be difficult,
so maybe it should just check to see whether wiki link ends in an 's'.

Very much dislike -> as unintuitive. Although for a reader it looks intuitive what it does, for a (first time) editor there is nothing intuitive about ->. They might remember it was an arrow, but then that could be: =>, ==>, -->, >>>, >, etc. MUCH more intuitive would be =. So:
[[link text = Namespace:Article]]
Even this is mildly unintuitive. Suggest completely new:
[link text [Namespace:Article]] interchangable: [[Namespace:Article] link text]
This would be followed by a reduction of wikilinking to [Namespace:Article], and an introduction of [text <whatever>] to create a caption of "text" around <whatever>.
--w:User:Alfakim.

-== Linking with URIs and email addresses ==-

  Syntax                                 Translation
  ------                                 -----------
  {{http://hackunix.org/}}               &lt;<a href="$1">$1</a>&gt;
                                         <http://hackunix.org/>

  {{derekm@hackunix.org}}                &lt;<a href="mailto:$1">$1</a>&gt;
                                         <derekm@hackunix.org>

  {{hackunix->http://hackunix.org/}}     <a href="$2">$1</a>
                                         <a href="http://hackunix.org/">hackunix</a>

  {{email me->derekm@hackunix.org}}      <a href="mailto:$2">$1</a>
                                         <a href="mailto:derekm@hackunix.org">email me</a>


-== Linking to other wikies ==-

Sometimes it may be necessary to link to other wikies.  Suppose you're writing
an article about anarchism, and you wish to create a simple link to Wikipedia's
immaculate section on the topic.  Instead of using {{ ... }} and linking to the
absolute URL (which may change in the future), you could use:

    [[Wikipedia::Anarchism]]

Or if you wish to define alternate text for the link,

    [[learn about anarchy->Wikipedia::Anarchism]]
.
Should the URLs to Wikipedia's content change, you won't have to hunt through
all your articles searching for affected links.  You can easily fix everything
with one change where ever the configuration of inter-wiki link keywords takes
place.

The syntax for linking inter-wiki is very similar to the syntax for accessing
namespaces (which we'll get to below).  However, to differentiate it from the
namespaces syntax, inter-wiki links use the double colon (::).

Where the inter-wiki links syntax is

    wiki - colon - colon - article-identifier
    [[wiki::article identifier]]
.
The namespaces syntax is

    namespace - colon - article-identifier
    [[namespace:article identifier]]
.
The inter-wiki namespaces syntax becomes

    wiki - colon - colon - namespace - colon - article-identifier
    [[wiki::namespace:article identifier]]    
.
And, while we're at it, the advanced features syntax is

    colon - keyword - colon - space - arguments-delimented-by-spaces
    [[:keyword: arg1 arg2 arg3 ...]]
.
This was done so advanced feature keywords won't conflict with inter-wiki link
keywords.


-== Namespaces and wiki links ==-

It may be desirable to have support for namespaces in wiki links and inter-wiki
links.  Namespaces would be useful for accessing special system pages, special
content categories, etc.  These links would be similar to normal wiki links or
inter-wiki links, except having a colon (:) separating the namespace from the
article identifier.  For example:

    [[namespace:article identifier]]
    [[special:site statistics]]
    [[Wikipedia::user:jizzbug]]
    [[discuss Wikitax->Metapedia::Talk:Wikitax]]

There are no spaces between namespace, colon (:), and article identifier.  This
is to allow article identifiers in the likes of:

    [[Magic: The Gathering]]
    [[Wikipedia::2001: A Space Odyssey]]



-= Advanced wiki links =-

When developing a plaintext markup language such as this, one sometimes desires
much more advanced features; such as embedding media (images, audio, video,
etc.) within article bodies or linking to that media within the text.
Fortunately, the wiki link double-square-brackets syntax lends itself to this
purpose quite naturally.  Instead of creating another syntax for users to
remember, we can employ square brackets to access the more advanced features
that we require.

The syntax for accessing these advanced features is

    [[:keyword: variables ...]]
.
Say we've attached an image to our article.  Including that image at some point
in our article, scaling it down 30%, and having it floated to the right for the
text to wrap around it, might look like

    [[:media: image.png scale="30%" align="right"]]
.
Or suppose that instead of embedding the image somewhere in the body of the
article and having the text flow around it, we wanted to provide a text link to
that image.  This might be achieved with

    [[an image in PNG format->:media: image.png]]
.
A precise syntax for this advanced features markup still needs to be fleshed
out.  What fundamental keywords would be needed or useful?  What should the
exact syntax be for the :media: keyword?  Et cetera.

Regardless of which keywords should be standardized and what their arguments
should be, this syntax for accessing advanced features is very useful.  It
provides a simple markup that is easy to understand and is easily extensible for
application specific needs.

Think about a syntax of [[wiki:::keyword: args ...]] for accessing advanced
portions of other wikies.  For example,

    [[Wikipedia:::media: /upload/d/d6/Lisbon_sisters.jpg align="left"]]

or

    [[Wikipedia:::media: Portland.jpg scale="125%" align="right"]]
.
Would these types of advanced inter-wiki links be desirable or necessary?
Both desirable and necessary for a good Web 2.0 implementation like we've been discussing :) -Nathan 21:48, 14 December 2005 (UTC)

-== Proposed syntax for :media: keyword ==-
 [[:media: filename variables ...]]
 [[link text->:media: filename variables ...]]

 filename
     If filename is specified as solely the filename, e.g. image.png, the media
       item is assumed to have been attached to the article itself, and it is
       found by checking the filenames of attached media items.  If filename is
       relative, e.g. /images/logo.png, the media item is assumed to be found
       at that relative path on the HTTP server.  If filename is absolute, e.g.
       ftp://ibiblio.org/pub/multimedia/pictures/historic-computing/pdp8_1.jpg
       or http://w3.org/Icons/w3c_home.png, the media item is assumed to be
       found at that location, optionally to be cached locally.
 height
     Specified as a pixel value or percentage.
 width
     Specified as a pixel value or percentage.
 scale
     Specified as a percentage, much simpler and more straight-forward than
       specifying both height and width.  Especially since height and width
       percentages are relative not to the natural size of the media, but to
       the available space within which to render the media (see
       <http://www.w3.org/TR/html4/struct/objects.html#visual>).
 caption
     Values of "on", "yes", or "1" would format the rendering of the embedded
       media to include a caption.  The caption would most likely come from a
       field in the database entry for that piece of media.
     Values of "off", "no", or "0" would turn off the rendering of the caption
       text.
     Any other values, that value becomes the caption; e.g.,
       caption="My favorite (and now dead) cat, Moorefield."
     Another possibility is that captions are off by default.  If 'caption' is
       given as an argument, captions are turned on for that media item, and
       the caption is pulled from the database.  If 'caption=' is given as an
       argument, captions are turned on for that media item, and the caption
       text is specified in quotes ("...") after the equal sign.
 alt [?]
     To specify alt text.  But would this really be necessary?  Couldn't alt
       just be populated with the caption text from the database, or from the
       caption text specified via 'caption='?
 align
     A value of "right" will "float" the media justified to the right with text
       wrapping around it.
     A value of "left" will "float" the media justified to the left with text
       wrapping around it.
     A value of "center" will center justify the media; text will not wrap, but
       will be split above and below the media at that point.
     If this variable is not specified, the media is displayed "inline" with
       text.  This is the same as specifying a value of "bottom".
     A value of "bottom" will vertically align the bottom of the media with the
       current baseline.  This is the default behavior in most UAs when
       alignment values are not specified.
     A value of "middle" will vertically align the center of the media with the
       current baseline.
     A value of "top" will vertically align the top of the media with the top
       of the current text line.
 type
     To specify the content type of the media; e.g., text/plain, image/png, or
       application/mpeg.  Most people probably wouldn't need to use this
       argument, but it's included for completeness.


If link text is specified, no variables need be specified, as their purpose is only served when the media is to be rendered within in the article body.
What arguments might be useful if the media are audio or video data, etc.?

-== Redirects ==-
As sites evolve and grow, content gets shuffled around. To keep these activities from breaking old links, a means of redirecting browsers from one location to another is needed. Conforming this idea to the advanced features syntax is fairly straight forward:
   [[:redirect: "article identifier"]]


Ideally, the redirect tag would be the only thing contained within the body of the article. At the very least, it should be at the very top of the body. If it occurs anywhere else, it ought to be ignored.

-== Includes ==-
Similar in nature to redirects, but inverting the concept somewhat, are includes. To avoid unnecessary replication/duplication of content, it might sometimes be useful to provide authors with the ability to include other content or sections of content. Authors should be able to either include the entire content, or a section of the content:
   [[:include: "article identifier" {section="section-name"}]]



-== Table of contents ==-
Dynamically generated tables of content would be very useful for making large articles more readable and navigable. The software could analyze the sections or headings of documents on the fly to create tables of content when it sees:
   [[:toc:]]



-== Proposed advanced feature for page breaks or form feeds ==-
It might be useful to provide authors with the functionality of being able to break up their articles into multiple pages. But what should the syntax for this feature be?
   [[:page-break:]]?
   [[:form-feed:]]?
   [[:pgbr:]]?
   [[:pb:]]?
   [[:ff:]]?
   all of the above?




-= Other stuff I need to write more about =-
Syntax Translation ------ -----------
  • item 1 <ul><li/>item 1
    • item 1.1 <ul><li/>item 1.1</ul>
  • item 2 <li/>item 2</ul>

  1. item 1 <ol type="1"><li/>item 1
    1. item 1.1 <ol type="1"><li/>item 1.1</ol>
  2. item 2 <li/>item 2</ol>


@ item A <ol type="A"><li/>item A @@ item A.a <ol type="a"><li/>item A.a</ol> @ item B <li/>item B</ol>
% item I <ol type="I"><li/>item I %% item I.i <ol type="i"><li/>item I.i</ol> % item II <li/>item II</ol>
+ item I <ol type="I"><li/>item I ++ item I.A <ol type="A"><li/>item I.A ++ item I.B <li/>item I.B +++ item I.B.1 <ol type="1"><li/>item I.B.1 +++ item I.B.2 <li/>item I.B.2</ol></ol> + item II <li/>item II ++ item II.A <ol type="A"><li/>item II.A +++ item II.A.1 <ol type="1"><li/>item II.A.1 ++++ item II.A.1.a <ol type="a"><li/>item II.A.1.a</ol> +++ item II.A.2 <li/>item II.A.2 ++++ item II.A.2.a <ol type="a"><li/>item II.A.2.a +++++ item II.A.2.a.i <ol type="i"><li/>item II.A.2.a.i +++++ item II.A.2.a.ii <li/>item II.A.2.a.ii</ol> ++++ item II.A.2.b <li/>item II.A.2.b</ol></ol></ol> + item III <li/>item III</ol>
---- <hr/>
[wb][sp]--[sp][wb] [wb][sp]&mdash;[sp][wb]
[wb][sp]-[sp][wb] [wb][sp]&mdash;[sp][wb]
[wb]--[wb] [wb]&mdash;[wb]
& (when '&' /<<: character entity) &amp;
< (when '<' /<<: markup tag) &lt;
> (when '>' /<<: markup tag) &gt;


-= Other stuff to think about more =-
Some suggest that syntaxes similar to '[[ ... | ... ]]' and '{{http://ls/ weird}}' are not intuitive. This criticism is valid, so we should all think about the matter. A nice alternative that has been suggested is employing pointers. Instead of the alternate text coming after the target, it comes before, with a nice lil' arrow pointing to the target:
   [[learn about anarchy->anarchism]]
   [[learn about anarchy from Wikipedia->:Wikipedia::Anarchism]]
   [[look at this picture of my cat->:media: moorefield.jpg]]
   [[my profile at Wikipedia->:Wikipedia::user:jizzbug]]
   {{check out Indymedia->http://www.indymedia.org/}}


Is this more intuitive? Do we likey?
END_of_Multiline_Text

I like it because in addition to whatever benefits you see, those lines can be (more easily) sorted (for example, in alphabetic order) based on what the reader sees vs. the address of the link. --SomeoneElse