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