The key characteristic we can use to distinguish the examples you’ve given is whether they transclude a variable or a tiddler. That determines the namespace we’re using: that of variables, whose names are only locally unique, and that of tiddlers, whose titles must be globally unique.
The challenge with transcluding tiddlers is that short tiddler titles (like “ref”) are visible in the sidebar lists, which one doesn’t necessarily want for templates that are not useful to end users on their own. Using system tiddlers is less concise: for example {{$:/ref|Source title|Chapter}}
.
There’s no such penalty for using short names for variables, but the converse is that there is no direct way to determine which tiddler was the origin of a particular definition, nor to easily browse the available variables/procedures/functions/macros.
Another useful dimension for analysing your three examples is that they offer different tradeoffs of verbosity vs. flexibility:
- The transclusion syntax
{{ref|Source title|Chapter}}
is the most concise, but the least flexible as one can only pass parameters by position, with no named parameters
- The macro/procedure syntax
<<ref "Source title" "Chapter">>
is less concise, but increases flexibility by allowing named parameters to be passed in any order
- The custom widget syntax
<$.ref source="Source title" chapter="Chaper"/>
is a little more verbose but increases flexibility further by allowing blocks of wikitext to be passed as parameters via the <$slot>
/<$fill>
mechanism
3.We could add the transclusion widget syntax <$transclude $tiddler="ref" source="Source title" chapter="Chaper"/>
that is again less concise but increases flexibility by allowing the name of the transclusion target to be computed
The core has some inchoate policies to help navigate the choices:
- Transclude named tiddlers for system templates that are used to construct the system user interface and do not generally need to be invoked within ordinary textual content (eg
$:/core/ui/PageTemplate
)
- Transclude global variables for system templates that are used to construct user interface components that are frequently invoked in ordinary textual content (eg
<<tag example>>
)
I suspect that more nuanced guidelines might emerge with usage, and the community making discoveries about the new syntax.