In example 108, the foo link is described twice. If people are going through the trouble of making something that can be declared as semantically verifiable, why allow a confusion construct?

If the intent is to just allow me to do:

[link]: url_a
Go check out [link].
[link]: url_b
go check out [link].

such that the first one is a link to url_a and the second one is a link to url_b, the current specification wouldn't be sufficient.

For the sake of sanity, it would just make more sense to disallow redeclaring link targets.

+++ eanderson [Sep 04 14 00:35 ]:

eanderson [1]eanderson September 3

In example 108, the foo link is described twice. If people are going through the trouble of making something that can be declared as semantically verifiable, why allow a confusion construct?

If the intent is to just allow me to do:

Go check out [link].

go check out [link].

such that the first one is a link to url_a and the second one is a link to url_b, the current specification wouldn't be sufficient.

For the sake of sanity, it would just make more sense to disallow redeclaring link targets.

The tradition in markdown parsers is not to raise errors. No matter how crazy the input, something is done with it. There is no such thing as an invalid markdown document.

So we need to say what to do when a duplicate link definition is given.

such that the first one is a link to url_a and the second one is a link to url_b

Since Markdown doesn’t exactly care where a link definition is made (usually, it’s placed at the end of the document), both links would go to url_a.

It would probably be a good idea to highlight this somewhere in the spec to make it clear that all link definitions are collected independently of their location.

If nothing else, if this is desired, putting a test case in place with this example would help ensure people don't get creative with their parsers.

It may be a big change, but could I argue in support for duplicate links being supported? That is,

Go check out [link].
[link]: url_a
go check out [link].
[link]: url_b

would produce two unique links.

The rationale is that Markdown documents should be composable. That is, if I concatenate two Markdown documents and compile them, it would be ideal if the output was roughly similar to just concatenating the output. (Mathematically, markdown(a) + "\n\n" + markdown(b) ~= markdown(a + "\n\n" + b)). This is ideal, because when copying and pasting various documents together, it would be ideal to not need to make global changes to the document. The current spec means that the links in the second document will be broken in the presence of duplicate label names.

An additional rationale is that allowing duplicate labels allows users to have short, "anonymous" labels for links, such as "1", "2", etc. This prevents users from having to either: (1) always use inline links or; (2) always invent globally unique labels for their links.

The [foo][1] is rather [bar][2].
[1]: http://example.com/1
[2]: http://example.com/2
...
The [baz][1] is still [zapped][2].
[1]: http://example.com/3
[2]: http://example.com/4

This proposal will introduce some challenges, such as "in the fact of duplicates, which link should be attached to which label?". I don't think there is a fully composable solution to this. I humbly suggest the following algorithm, however:

1. A link uses the first label defined after it appears.
2. If no label appears after a link, the link uses the closest label defined above.

For example, the following markdown:

[a]
[a]: http://www.x.com/
[a]
[a]: http://www.y.com/
[a]

using this spec should compile to:

<p><a href="http://www.x.com/">a</a></p>
<p><a href="http://www.x.com/">a</a></p>
<p><a href="http://www.y.com/">a</a></p>

The rationale for this algorithm is that in my survey of Markdown documents, people tend to define labels after the corresponding link. Rule (2) provides backwards compatibility for documents that define links before, and don't currently use duplicates.

Thoughts on this proposal would be appreciated.