Elements of a Hypermedia Message Document

Per issue #4, this is the first draft of this document describing the elements of a hypermedia message. It is all open for discussion, and I'd be happy to change anything. Below are some discussion items.

- [x] 1. Is the categorization of transitions helpful?
- [x] 2. Should this include the concept of curies or prefixes?
- [x] 3. Is the concept of anonymous links and actions helpful?
- [x] 4. Does it make sense to include embedded resources under transitions?
- [x] 5. How do we address more complex attributes? Ones that may include arrays of objects in JSON or nested elements in XML?

Once we come to a consensus, we can merge it into the repo. Thanks!
@zdne Yes, this is close to what I'm saying. Let me walk through some thoughts.

Let's say you have a URI template `/customers/{id}/orders{?year}`. Many media types and libraries group all of these parameters as simply URI template parameters ([example](https://github.com/geraintluff/uri-templates)). In other words, there is no way to differentiate between the different types of parameters you have listed in many cases (though there could be).

Additionally, some media types allow for query parameters (HTML, Cj, etc.). In this situation, using a URI template that has query parameters, but expressing those as query parameters doesn't work.

Fake example with a fake media type:

```json
{
  "templates": [
    {
      "href": "/customers/{id}/orders{?year}",
      "uriParams": [
        { "name": "id" },
        { "name": "year" }
      ],
      "queryParams": [
        { "name": "year" }
      ]
    }
  ]
}
```

Since as a client user I'm not inspecting what each URI parameter is, it looks like I have a `year` URI parameter *and* and `year` query parameter. This is the reason URI template parameters using `{?var}` should be mixed with normal query parameters.

So to your question about API Blueprint, I'm not sure the best way to handle this, because there are more parts of the URL than the ones you've listed. There is the dot prefix `{.var}`, among others. Documenting path segments (which can be `{/var}` or `{var}`) at the resource level and query params and fragment params at the action level seems like a good way to go.

Just to complicate things... this does not all for URLS like `http://example.com/#/something` to work, as it has a path in the fragment (yikes!).