Extension Syntax/Voting

'Voting will last until April 12, 2004, 20:00 UTC. PLEASE DO NOT VOTE UNLESS YOU UNDERSTAND THE PROBLEM. THIS IS ABOUT FINDING A SYNTAX TO ENCAPSULATE DIFFERENT EXTENSIONS, NOT ABOUT THE SYNTAX OF THE EXTENSIONS THEMSELVES.

This is a vote on the new syntax for MediaWiki extensions. Make sure you have read the introduction and proposals before voting; examples are also available.

Only registered users can vote. You can vote for any number of options, but not for and against an option, and not for a single option multiple times.

(note also that the structure of this vote is still under discussion)

Erik's proposal
See details and examples

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;

Votes for Erik's proposal

 * 1) Eloquence 00:18, 6 Apr 2004 (UTC)
 * 2) MinutiaeMan 00:29, 6 Apr 2004 (UTC)
 * 3) Toby Bartels 01:22, 6 Apr 2004 (UTC)
 * 4) A &#9774; ineko 02:35, 6 Apr 2004 (UTC)
 * 5) mav 03:01, 6 Apr 2004 (UTC)
 * 6) Treanna 05:15, 6 Apr 2004 (UTC)
 * 7) Arvindn 05:40, 6 Apr 2004 (UTC)
 * 8) grin 10:17, 6 Apr 2004 (UTC)
 * 9) Jamesday 11:10, 6 Apr 2004 (UTC) (with the proviso that all of these extensions should start with the word wiki to avoid namespace conflicts)
 * 10) Phil 15:21, 6 Apr 2004 (UTC) (same proviso as Jamesday
 * 11) Sansculotte 15:23, 6 Apr 2004 (UTC)
 * 12) The Anome 15:37, 6 Apr 2004 (UTC)
 * 13) Angela 15:44, 6 Apr 2004 (UTC)
 * 14) Nohat 17:44, 6 Apr 2004 (UTC)
 * 15) IMSoP 18:07, 6 Apr 2004 (UTC) (without Jamesday's proviso, which essentially creates a new option)

Votes against Erik's proposal

 * 1) Timwi 09:05, 6 Apr 2004 (UTC) :-p
 * 2) Evan 14:54, 6 Apr 2004 (UTC)

Magnus' proposal
See details and examples

For images: can produce a PNG or an SVG, depending on user settings or browser identification.

For more complex structures (hiero, music): to use "stuff" as data; or to use data stored in stuff.

Alternative for page reference (result of discussion):

Votes for Magnus' proposal

 * 1) A &#9774; ineko 02:35, 6 Apr 2004 (UTC) (but can't use }} in code may be a problem)
 * 2) Angela 15:44, 6 Apr 2004 (UTC)

Votes against Magnus' proposal

 * 1) Eloquence 00:20, 6 Apr 2004 (UTC) (too confusing with existing use of curly brackets, inline code will get hard to read)
 * 2) MinutiaeMan 00:30, 6 Apr 2004 (UTC) (wouldn't this conflict with existing math formulae?)
 * 3) Timwi 09:06, 6 Apr 2004 (UTC)
 * 4) Phil 15:32, 6 Apr 2004 (UTC) (too fiddly and confusing)
 * 5) The Anome 15:40, 6 Apr 2004 (UTC), too fiddly
 * 6) Nohat 17:44, 6 Apr 2004 (UTC)
 * 7) IMSoP 18:09, 6 Apr 2004 (UTC) (ambiguous wrt to other uses of curly brackets)

Neutral

 * 1) grin 10:17, 6 Apr 2004 (UTC)

Forum like (with no /) (Aoineko)
See details and examples
 * [math]...[math]
 * [hiero]...[hiero]
 * [music]...[music]

Votes for

 * 1) A &#9774; ineko 02:35, 6 Apr 2004 (UTC)

Votes against

 * 1) Timwi 09:06, 6 Apr 2004 (UTC)
 * 2) grin 10:17, 6 Apr 2004 (UTC) (I always hated that form, it looks like it's optional)
 * 3) Phil 15:33, 6 Apr 2004 (UTC)
 * 4) Angela 15:44, 6 Apr 2004 (UTC)
 * 5) Nohat 17:44, 6 Apr 2004 (UTC)

Forum like (with same end marker) (Aoineko)
See details and examples


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

Votes for

 * 1) A &#9774; ineko 07:11, 6 Apr 2004 (UTC)

Votes against

 * 1) Timwi 09:06, 6 Apr 2004 (UTC)
 * 2) grin 10:17, 6 Apr 2004 (UTC)
 * 3) Phil 15:34, 6 Apr 2004 (UTC)
 * 4) Angela 15:44, 6 Apr 2004 (UTC)
 * 5) Nohat 17:44, 6 Apr 2004 (UTC)

Magnus' proposal alternative 2 (Aoineko)
See details and examples


 * 


 * 
 * </tt>

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.

Votes for

 * 1) A &#9774; ineko 02:35, 6 Apr 2004 (UTC) (but can't use }} in code may be a problem)
 * 2) Angela 15:44, 6 Apr 2004 (UTC)

Votes against

 * 1) grin 10:17, 6 Apr 2004 (UTC) (ambiguity sucks)
 * 2) Phil 15:34, 6 Apr 2004 (UTC) (too confusing)
 * 3) Nohat 17:44, 6 Apr 2004 (UTC)

Neutral

 * 1) Timwi 09:07, 6 Apr 2004 (UTC)

Uli's Proposal
See details and examples

Abstract: This is essentially a variant of Erik's proposal with more intelligent templates.

Summary: fragments would be included with the already disussed syntax , . For not-included data, I'd prefer the XML-type syntax ( $$$$ )

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! 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.

Votes for Uli's proposal

 * 1) Toby Bartels 01:22, 6 Apr 2004 (UTC)

Votes against Uli's proposal

 * 1) Eloquence (Much of this is already obsolete, because we will get the Template: namespace for that purpose; having templates associated with extensions is not worth the added code complexity - you just save an opening and closing tag. The auto-positioning idea is interesting, that would have to developed further though.)
 * 2) Timwi 09:07, 6 Apr 2004 (UTC)
 * 3) grin 10:17, 6 Apr 2004 (UTC)
 * 4) Angela 15:44, 6 Apr 2004 (UTC)
 * 5) Nohat 17:44, 6 Apr 2004 (UTC)

Peter's proposal
See details and examples



Votes for Peter's proposal

 * 1) Angela 15:44, 6 Apr 2004 (UTC)

Votes against Peter's proposal

 * 1) Toby Bartels 01:22, 6 Apr 2004 (UTC)
 * 2) Timwi 09:08, 6 Apr 2004 (UTC) (strongly against)
 * 3) grin 10:17, 6 Apr 2004 (UTC)
 * 4) Nohat 17:44, 6 Apr 2004 (UTC)

Inline brackets proposal
See details and examples


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

Votes for inline brackets proposal

 * 1) Timwi 09:09, 6 Apr 2004 (UTC)
 * 2) grin 10:17, 6 Apr 2004 (UTC)

Votes against inline brackets proposal

 * 1) Phil 15:35, 6 Apr 2004 (UTC) (just bizarre)
 * 2) Angela 15:44, 6 Apr 2004 (UTC)
 * 3) Nohat 17:44, 6 Apr 2004 (UTC)

Symbol bracket proposal
See details and examples...

Votes for symbol bracket proposal

 * 1) Timwi 09:08, 6 Apr 2004 (UTC)

Votes against symbol bracket proposal

 * 1) Toby Bartels 01:22, 6 Apr 2004 (UTC)
 * 2) grin 10:17, 6 Apr 2004 (UTC) ("hard to memorize even for perlmongers")
 * 3) Phil 15:36, 6 Apr 2004 (UTC) (even more bizarre)
 * 4) The Anome 15:38, 6 Apr 2004 (UTC)
 * 5) Angela 15:44, 6 Apr 2004 (UTC)
 * 6) Nohat 17:44, 6 Apr 2004 (UTC)

IMSoP's proposal
See details and examples

 ... </tt>  ... </tt>

Votes against IMSoP's proposal

 * 1) Timwi 09:09, 6 Apr 2004 (UTC)
 * 2) grin 10:17, 6 Apr 2004 (UTC) (hard to type)
 * 3) Angela 15:44, 6 Apr 2004 (UTC)
 * 4) Nohat 17:44, 6 Apr 2004 (UTC)

Phil's proposal
See details and examples

 ... ...  ... </tt>

Votes for Phil's proposal

 * 1) Toby Bartels 01:22, 6 Apr 2004 (UTC)
 * 2) A &#9774; ineko 02:35, 6 Apr 2004 (UTC)
 * 3) Jamesday 11:10, 6 Apr 2004 (UTC) simple but it's good to have the end tag clearly linked to the start tag type, so I favor Erik's proposal of the two I support.
 * 4) Angela 15:44, 6 Apr 2004 (UTC)

Votes against Phil's proposal

 * 1) Timwi 09:10, 6 Apr 2004 (UTC)
 * 2) grin 10:17, 6 Apr 2004 (UTC) (hard to type)
 * 3) Nohat 17:44, 6 Apr 2004 (UTC)

Saff's proposal
See details and examples

''Note: This is not a generic proposal as it does not allow for arbitrary extensions. However, it does allow for a certain type of user-created extensions. If you think that is enough, or should be used in addition to the other proposals, vote for this one.''

So, what I think would be perfect for many things (games, music, probably not svg) is create a new namespace, called markup or something. On a "markup" page, certain text strings can be marked with replacement by any object (different text, images, etc.):

Maybe something like: ... == Text to replace == Comments about this item.
 * 1) What to replace it with

For inline markup, just {{markup:music} a b c# } should work.

Votes against Saff's proposal

 * 1) Eloquence (most viable extensions are far too complex for such a scheme, and even things like chess benefit from a truly specialized syntax; maybe in addition to a regular extension syntax, but certainly not as the main solution)
 * 2) Timwi 09:10, 6 Apr 2004 (UTC)
 * 3) Phil 15:38, 6 Apr 2004 (UTC) (too specialised)
 * 4) Angela 15:44, 6 Apr 2004 (UTC)
 * 5) Nohat 17:44, 6 Apr 2004 (UTC)