Support for Semantic/Common Hypermedia?

[nikmd23]

Seems to me like release notes in general benefit greatly from hypermedia support.

Technically, the current proposal for SRN supports hypermedia via markdown's built in inline link syntax:

This is [an example](http://example.com/ "Optional Title Here") inline link.

What would be better is if SRN supported "link relations", which could just use markdown's out of the box reference link syntax:

This is [an example] [id] reference link.

`[id]: http://example.com/  "Optional Title Here"

With this, we could support known rel's what are common, such as license, homepage, installation, etc.

Here's a full example:

This is a _project_ summary of some great [new software][homepage]. 
[Installing][installation] is a bit tricky right now, but we hope to work on that.

 - Made the UI red
 - Changed to [Apache 2][license]
 - Was influenced by the [Refactoring](http://www.refactoring.com/) book.

`[homepage]: http://newsoftware.com/ "DevCo"
`[installation]: http://newsoftware.com/howToInstall  "Installation notes"
`[license]: http://opensource.org/licenses/Apache-2.0

From this, UI's could use indicators for well known link types. Rel's would be extensible, but we'd have a suggested list.

Note: Examples of reference links have a ` character to stop GitHub's rendering from hiding said syntax

[nikmd23]

I'd also propose a packagefeed rel based on the Feed Discovery work the MyGet team is doing.

[nikmd23]

Last thought on this, for now.

We'd also need to support the concept of a multi-valued rel. For example, there could be several links to users:

We really want to thank [Bob][user-twitterBob] and [Suzy][user-suzyTweets].

`[user-twitterBob]: http://twitter.com/twitterBob
`[user-suzyTweets]: http://twitter.com/suzyTweets

In this case, the rel user has multiple values, noted by a - character.

[avanderhoorn]

I agree with the above, but I'm wondering how this differs from the link support MarkDown already offers?

The following is from the MarkDown syntax page:

Reference-style links use a second set of square brackets, inside which you place a label of your choosing to identify the link:
This is [an example][id] reference-style link.

You can optionally use a space to separate the sets of brackets:
This is [an example] [id] reference-style link.

Then, anywhere in the document, you define your link label like this, on a line by itself:

[id]: http://example.com/ "Optional Title Here"

The biggest difference I see is the preceding tick. My concern with this is that if the block is parsed by a normal MarkDown parser, it won't just render as expected.

[nikmd23]

@avanderhoorn,

Reread the original comment. In particular these two sentences:

which could just use markdown's out of the box reference link syntax

and

Note: Examples of reference links have a ` character to stop GitHub's rendering from hiding said syntax

[avanderhoorn]

Ok, so in the end I think all your saying is supporting MD style links. Or any I still missing something.

[nikmd23]

I'm saying that we would just use that syntax.

But perhaps I have a link that doesn't have any specific text. Let me give another example:

This is a _project_ summary of some great [new software][homepage]. 
[Installing][installation] is a bit tricky right now, but we hope to work on that.

 - Made the UI red
 - Was influenced by the [Refactoring](http://www.refactoring.com/) book.

`[homepage]: http://newsoftware.com/ "DevCo"
`[installation]: http://newsoftware.com/howToInstall  "Installation notes"
`[license]: http://opensource.org/licenses/Apache-2.0

Notice in this example, a re-hash from an earlier example, there is a license link that is unused. We should still parse out this link, even though it is not used in the text, and make it available in the data object. (Because it is named license and license could be a well defined relation.

[nikmd23]

I propose we add this to the spec. @shiftkey, do you have any thoughts?

[shiftkey]

[avanderhoorn]

Agreed +1

On Saturday, April 6, 2013, Brendan Forster wrote:

[image: MakeItSo]https://f.cloud.github.com/assets/359239/346343/7ec4f4aa-9e40-11e2-90d2-93ec386d8002.gif

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/7#issuecomment-15984309
.