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!
So when it comes to URI templates we have (among others):

1. Variable (Path Segment Expansion) – `{var}` / `{/var}`
2. Form-Style Query Expansion – `{?var}`
3. Form-Style Query Continuation –  `{&var}`
4. Fragment Expansion – `{#var}`

Now if I understand you correctly you suggest to refrain from using `Form-Style Query Expansions`  in URI templates, instead specify these query parameters as "input parameters". Instead use URI templates only for path segment expansions (without query parameters)? What about fragments? 

For your information – This is actually something I grapple with in API Blueprint – when it comes to URI templates. Currently, in API Blueprint, one must specify all parameters including query parameters in Resource' URI template and then document respective query parameters at relevant  actions (transitions). This is causing a lot of confusion.

I think it would be better to apply the same logic there – write URI templates without query params, and instead document query parameters at respective actions.

Note I do not want to discuss blueprint-related stuff here, just thinking out loud, and getting to the conclusion that your idea, if I get it right, could actually make our lives easier!