MultilinePlaceholderProposal#
I've added a link to MultilinePlaceholderProposal, which 77.128.31.184 must have missed. The advantage of MultilinePlaceholderProposal is that it begins with a globally unique identifier (reversed domain name, like packages in Java).
--YvesPiguet, 07-Feb-26
I've been wanting to discuss this particular aspect of the proposal, just waited for the page to settle down. I believe that while we can suggest a plugin-naming scheme, the exact solution used is up to the wiki engine developer. It's very similar situation to how the page names in links and image names are treated -- the existing engines have such a wide range of working solutions that it would be impossible to come up with one that everyone agrees on.
Besides, the domain-like notiation is unnecessarily elaborate for something that is in common everyday use. It's ok for things like DTD that are usually copy-pasted or included in ready-made templates. It's ok for programming languages -- especially when you make some aliases to them anyways. But it'd be unacceptable to write about that <<unaffiliated.radomir.dopieralski.macro.latex source="$x_2$">> symbol as referenced in <<unaffiliated.radomir.dopieralski.macro.latex source="$x_2+y=c$">> formula using these elaborate names.
I say that leaving the plugin-naming conventions to the wiki engine has even more sense that for page names and images -- because these extensions cannot be moved between wikis anyways, so we really don't need any interoperability inside the box.
-- RadomirDopieralski, 2007-02-26
I think I would like to see this expanded alittle to optionally allow alternative content. Which would serve two purposes.
- When wiki engine doesn't know a plugin it can use the alternative. Like HTML's object element.
- Plain text markup can still make sense.
As for naming, I do think the dotted form is excessive. And certainly wouldn't want the plugging name embeddeded directly in the wiki markup. If I wrote a different latex plugin with the same interface as unaffiliated.radomir.dopieralski.macro.latex, I won't want to have to change the markup.
-- JaredWilliams, 2007-02-26
You have the choice between possible name clashes which must be handled in an ad hoc fashion, or some unique identifier. With unique identifiers, you can have a central repository, which is painful to manage, or a way to delegate naming to multiple people like with my proposition, with slightly longer names (of course nobody would ever choose something like unaffiliated.radomir.dopieralski.macro.latex). If you accept name clashes, it isn't worth having it in the standard, and it isn't worth having alternative contents because you can't be sure you won't map to your plugin something else with the same name.
To please everybody, I'd suggest that names with dots be reserved for reversed domains for people who care about the issue, but by experience, I feel it's a loosing battle.
-- YvesPiguet, 2007-02-27
The canonical domain name for my university's faculty is wmid.amu.edu.pl. This is actually very short, as we use acronyms both for the unversity and the faculty name. Other universities/faculties domain names tend to be longer. A lot of development happens on universities: you'd then have pl.edu.amu.wmid.macro.latex (the "macro" keyword is needed to distinguish it from similar plugins, like parser.latex, colorizer.latex or import.latex).
I agree about the choice between possible clashes and nice and clean namespace, and also about the benefits that allow you to make central repositories, indexing, put important documentation online, etc. But I believe that the choice is not ours to make -- it's up to the developer.
If you want to start standarizing the extension names themselves, you open a Pandora box of internationalisation and localisation. On a Polish-only wiki, I will naturally want to use polish names for plugins. But domain names don't allow (by default) the use of characters like ą or ę. I believe that Chinese users would have even more trouble.
I like the idea of an "alt text", I think the same syntax that is used for images, <<plugin paramaters|alt text>> would be apropriate? Of course, the alt text would be probably somehow distinguished from the normal text (tinted background? red text? frame around it?). I wonder what should be rendered when the plugin is missing and there is no alt text specified -- displaying the parameters might be too much (although they would usually give some hint on the intended contents), maybe just the name of the missing plugin?
Yves, I don't quite understand this sentence:
If you accept name clashes, it isn't worth having it in the standard, and it isn't worth having alternative contents because you can't be sure you won't map to your plugin something else with the same name.
Can you please elaborate?
-- RadomirDopieralski, 2007-02-27