The most recent spec 0.31.2 says this about the structure of inline links:
An inline link consists of a link text followed immediately by a left parenthesis (, an optional link destination, an optional link title, and a right parenthesis ). These four components may be separated by spaces, tabs, and up to one line ending. If both link destination and link title are present, they must be separated by spaces, tabs, and up to one line ending.
… and this about link reference definitions for reference links:
A link reference definition consists of a link label, optionally preceded by up to three spaces of indentation, followed by a colon (:), optional spaces or tabs (including up to one line ending), a link destination, optional spaces or tabs (including up to one line ending), and an optional link title, which if it is present must be separated from the link destination by spaces or tabs. No further character may occur.
Note that the link destination is explicitly optional in inline links but apparently mandatory in reference link definitions.
Examples 199 and 200 show the difference between missing and empty link destinations in reference link definitions.
Examples 485 and 486 show that there is no such difference between missing and empty link destinations in inline links.
There are no examples that show title-only link definitions without a link destination nor with an empty link destination.
[link text]("link title")
[link text](<> "link title")
[link text][link label]
[link label]: "link title"
[link label]: <> "link title"
I do not know whether this difference for link destinations between inline and reference links is intentional. I would like it to be optional in both cases, because that is consistent and somewhat enables a path to backwards-compatible extensions (but see below), but, unfortunately, most implementations actually require the link destination in both cases, so maybe the spec for inline links should be changed accordingly.
Dingus
Babelmark3
Examples 209 and 210 demonstrate that nothing except whitespace is allowed after the (optional) link title in reference link definitions.
There is no corresponding example for inline links.
This would be fine for a monolithic spec, but for extensibility, it would be better if other characters were allowed between link title and closing parenthesis (or line end, respectively), which would remain unparsed like info strings in fenced code blocks.
[text](<destination> "title" #id .class @attribute)
The most recent spec 0.31.2 says this about the structure of inline links:
… and this about link reference definitions for reference links:
Note that the link destination is explicitly optional in inline links but apparently mandatory in reference link definitions.
Examples 199 and 200 show the difference between missing and empty link destinations in reference link definitions.
Examples 485 and 486 show that there is no such difference between missing and empty link destinations in inline links.
There are no examples that show title-only link definitions without a link destination nor with an empty link destination.
I do not know whether this difference for link destinations between inline and reference links is intentional. I would like it to be optional in both cases, because that is consistent and somewhat enables a path to backwards-compatible extensions (but see below), but, unfortunately, most implementations actually require the link destination in both cases, so maybe the spec for inline links should be changed accordingly.
Dingus
Babelmark3
Examples 209 and 210 demonstrate that nothing except whitespace is allowed after the (optional) link title in reference link definitions.
There is no corresponding example for inline links.
This would be fine for a monolithic spec, but for extensibility, it would be better if other characters were allowed between link title and closing parenthesis (or line end, respectively), which would remain unparsed like info strings in fenced code blocks.