==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