Extension Syntax

This page is used to discuss and vote on a syntax for extensions to the MediaWiki software. These include:
 * LaTeX (mathematics, formulas, chess..)
 * musical notes (Lilypond)
 * plots and timelines (gnuplot, ploticus, EasyTimeline)
 * SVG->PNG rendering
 * How does this one need any special syntax ? You just use [[Image:foo.svg]] and it should be converted to PNG unless the user chose otherwise in preferences. Taw 18:47, 28 Mar 2004 (UTC)
 * SVG should be editable to fix labels in diagrams, etc. How do we best accomplish that in your scheme?&mdash;Eloquence
 * By being able to edit the text at Image:foo.svg R3m0t 08:14, 29 Mar 2004 (UTC)
 * That text is the image description page. It should not be abused for source code.&mdash;Eloquence
 * SVG is not meant for editing by hand &mdash; just download it, open in some SVG editor, fix and reupload. Taw 01:56, 30 Mar 2004 (UTC)
 * hieroglyphs (WikiHiero)
 * map rendering
 * anything else that's cool and useful

There will be a brainstorming phase of 7 days, after which voting will start on these proposals (on April 4). The voting phase will last seven days (until April 11).

Erik's proposal
We should use an XML-like syntax for extensions:
 * 1) &lt;math&gt;insert code here&lt;/math&gt;
 * 2) &lt;music&gt;insert code here&lt;/music&gt;
 * 3) &lt;hiero&gt;insert code here&lt;/hiero&gt;

Long code segments could be moved into the template namespace and transcluded in the standard manner, e.g. Template:Beethoven's 9th Symphony (sample) would contain the &lt;music&gt;...&lt;/music&gt; code, and could be transcluded using.

Rationale:
 * Many people are already familiar with XML-style syntax
 * It is immediately obvious over long segments of code what class a particular segment belongs to (i.e. you can look at the bottom of a music segment and know that it is music code, because there's a &lt;/music&gt; closing tag)
 * It is easy to remember
 * It is sufficiently unique to avoid parsing problems (as opposed to a short sequence of control characters, which might conflict with any present or future extensions)
 * It is easy to standardize the parser for it
 * It is wiki-like, as opposed to a more complex &lt;rend class="music"&gt; syntax, which is more suitable for programmers than users

Arguments against:
 * In short segments of code the redundant closing tag can be annoying
 * Needs to be localized (easy using Tim's MagicWord class, which also allows for synonyms, e.g. the English version could be valid in all translations to allow for easy copy & pasting)

Ivo's Proposal
I think the XML-Syntax like $$$$ ist no good solution. You have to write a long tag often for a smal formula. I would prefer something like


 * 1) [$ formula $] and
 * 2) [$$ formular $$].

The first expression stands for normal formulars appearing inside text the other one for formulars that should appear centered in an extra-line (but are notated in that text since there belonging to it). The $-sign is the normal symbol in TeX for formulars inside text the "$$-sign" for formulars that should appear in an extra-line. Since wie use TeX to notate formulars this would be a consitent solution. Of course we can use other braces than "[" and "]".


 * How to differentiate the type of data (tex, score, hieroglyph, etc.)? A &#9774; ineko 17:15, 28 Mar 2004 (UTC)
 * Thats just the proposal for math-markup (TeX). I did'nt say anything about score, hieroglyphs, etc.

Pros : Cons :
 * And if we need ]] in markup ? Regular expression to match \[\[.*\]\] is not a "parser". Taw 18:50, 28 Mar 2004 (UTC)
 * Sorry, I did not really understand the problem, could you explain it more detailed...?

Oh, and there is another point. I would like to see a small change for the headings-markup. Instead of "=== heading ===" we should use just "=== heading" since this allways apears in an extra-line and do not need parethis (? right word ?). Its from the formating-position the same like "#" for enumeration or "*" for itemizing (its describing a complete block not text inside a block).

Magnus' proposal
I think we should stick to the existing syntax that has proven to be understandable by most users. can produce a PNG or an SVG, depending on user settings or browser identification. That can utilize goodies like thumbnail generation etc. An image is an image is an image, after all.

for more complex structures (hiero, music), I suggest or. The first variant will use "stuff" directly as data, while the second one will use the data stored in stuff. That way, a complicated timeline can get its own "article" (I suggest a "data:" namespace), while a few hieroglyphs can be entered directly.


 * Good idea I think, but ':' and '::' are easy to confuse. A &#9774; ineko 02:55, 29 Mar 2004 (UTC)

Pros :
 * Simple syntax
 * Consistent with existing syntax
 * – parser is already in place
 * Allows for easy handling of large amounts of raw data without cluttering the article source

Cons :
 * Needs to be localized (easy using Tim's MagicWord class, which also allows for synonyms, e.g. the English version could be valid in all translations to allow for easy copy & pasting)
 * And if we need }} in markup ? Regular expression to match is not a "parser". Taw 18:50, 28 Mar 2004 (UTC)
 * Why not? I fail to see the problem here. If you want to display two curly braces in the text, put them in &lt;nowiki&gt; tags. -- Stw 10:45, 29 Mar 2004 (UTC)
 * 2 curly braces in embedded markup, not in text: $$\frac{10^{15}}{\pi}$$ ( \frac{10^{15}}{\pi} ). That's very common combination in TeX. One of the reasons why I chose $$$$ was because there's no chance in hell that   would appear in math markup. Taw 01:56, 30 Mar 2004 (UTC)

Aoineko' proposals
In fact, I fully support, but like we are in a brainstorming phase, I put here some ideas.

Forum like

 * [math]...[/math]
 * [hiero]...[/hiero]
 * [music]...[/music]

Forum like (with no /)

 * [math]...[math]
 * [hiero]...[hiero]
 * [music]...[music]

Forum like (with same end marker)

 * [math]...[end]
 * [hiero]...[end]
 * [music]...[end]

Magnus' proposal alternative 1
directly as data



from data page
 * math:...
 * hiero:...
 * music:...

Magnus' proposal alternative 2




Where the software check if foo is a valid page (data:foo). If true, parse the data page; If not, parse the text in tags.

Magnus' proposal alternative 3
directly as data



from data page (like #redirect )

Uli's Proposal
I had suggested a thing like that some time ago in the discussion on navigation bars. As I understand, we have some issues, that should be covered:


 * Navigational data (like theme-rings, article grouping ("history of germany, part 1..)) which should not be rendered at the position they are placed in the text, but instead at a - probably skin specific - position, and possibly only in certain situations (for example, theme rings should not be rendered in a print view).
 * Defining short non-textual data within articles (Hieroglyphs), to be rendered at the position where they are placed
 * Including long non-textual data, to be rendered at the position where they are placed
 * Possibly also including long non-textual data, to be rendered at a specific position (I'm thinking at those large information tables in the upper right corner of states, cities, elements and so on)
 * Probably we want to have some sort of parameters to pass to a transcluded item

So, suppose we get a namespace "Include:". We would seperate that namespace again by convention into type-specific segments, so article fragments containing music data would to be named "Include:Music:Beethovens 9th Symphony", Tabluar data to be included into an article would be named "Include:Table:Dollar rate since 1991", the big tables (upper right corner) possibly "Include:Infotable:Uranium", a navigation bar "Include:Navlist:10 largest cities of Island" and so on. It's important to have the type of the included data somehow coded into the article name, so you can render that fragment stand-alone!

Those fragments would be included with the already disussed syntax , . For not-included data, I'd prefere the XML-type syntax ( $$$$ ) - transcluding is something different than switching the syntax within the article, so we should seperate those two use-cases.

Very important: depending on the type (Music, Infotable, Navigation, ) of a transcluded fragment the software should not only decide on how to interpret the given data, but also on when and where to render.

From wikitech-l (1)


pros: cons:
 * complex syntax, which is more suitable for programmers than users

From wikitech-l (2)

 * [!math x^2 + y^2 = z^2  !]
 * [!hiero b-l:a-h  !]
 * [!music do re mi fa sol !]

From wikitech-l (3)

 * ! x^2 + y^2 = z^2 ! // math
 * ^ b-l:a-h ^ // hiero
 * // music

pros: cons: Taw
 * no key word to translate
 * can't use delimiter tags into the code
 * Looks like a link, but isnt