diff --git a/specification/00_basis.rst b/specification/00_basis.rst
index 10709f1d..f6d50802 100644
--- a/specification/00_basis.rst
+++ b/specification/00_basis.rst
@@ -171,13 +171,14 @@ All data exchanged over Matrix is expressed as an "event". Typically each client
 action (e.g. sending a message) correlates with exactly one event. Each event
 has a ``type`` which is used to differentiate different kinds of data. ``type``
 values MUST be uniquely globally namespaced following Java's `package naming
-conventions
-<http://docs.oracle.com/javase/specs/jls/se5.0/html/packages.html#7.7>`, e.g.
+conventions`_, e.g.
 ``com.example.myapp.event``. The special top-level namespace ``m.`` is reserved
 for events defined in the Matrix specification - for instance ``m.room.message``
 is the event type for instant messages. Events are usually sent in the context
 of a "Room".
 
+.. _package naming conventions: https://en.wikipedia.org/wiki/Java_package#Package_naming_conventions
+
 Event Graphs
 ~~~~~~~~~~~~
 
diff --git a/specification/10_client_server_api.rst b/specification/10_client_server_api.rst
index fe11d199..f0416c02 100644
--- a/specification/10_client_server_api.rst
+++ b/specification/10_client_server_api.rst
@@ -932,11 +932,8 @@ directly by sending the following request to
     "membership": "leave"
   }
 
-See the `Room events`_ section for more information on ``m.room.member``.
-
-Once a user has left a room, that room will no longer appear on the
-|initialSync|_ API.
-
+See the `Room events`_ section for more information on ``m.room.member``. Once a
+user has left a room, that room will no longer appear on the |initialSync|_ API.
 If all members in a room leave, that room becomes eligible for deletion.
 
 Banning users in a room
diff --git a/specification/20_events.rst b/specification/20_events.rst
index b0d5d716..ffc23ec4 100644
--- a/specification/20_events.rst
+++ b/specification/20_events.rst
@@ -92,11 +92,10 @@ Voice over IP
 -------------
 Matrix can also be used to set up VoIP calls. This is part of the core
 specification, although is at a relatively early stage. Voice (and video) over
-Matrix is built on the WebRTC 1.0 standard.
-
-Call events are sent to a room, like any other event. This means that clients
-must only send call events to rooms with exactly two participants as currently
-the WebRTC standard is based around two-party communication.
+Matrix is built on the WebRTC 1.0 standard. Call events are sent to a room, like
+any other event. This means that clients must only send call events to rooms
+with exactly two participants as currently the WebRTC standard is based around
+two-party communication.
 
 {{voip_events}}
 
@@ -106,25 +105,26 @@ A call is set up with messages exchanged as follows:
 
 ::
 
-   Caller                   Callee
+   Caller                    Callee
+ [Place Call]
  m.call.invite ----------->
  m.call.candidate -------->
- [more candidates events]
-                         User answers call
-                  <------ m.call.answer
-               [...]
-                  <------ m.call.hangup
+ [..candidates..] -------->
+                           [Answers call]
+          <--------------- m.call.answer
+    [Call is active and ongoing]
+          <--------------- m.call.hangup
 
 Or a rejected call:
 
 ::
 
-   Caller                   Callee
- m.call.invite ----------->
- m.call.candidate -------->
- [more candidates events]
-                        User rejects call
-                 <------- m.call.hangup
+   Caller                      Callee
+ m.call.invite ------------>
+ m.call.candidate --------->
+ [..candidates..] --------->
+                            [Rejects call]
+            <-------------- m.call.hangup
 
 Calls are negotiated according to the WebRTC specification.
 
@@ -137,9 +137,8 @@ better experience for the users if their calls are connected if it is clear
 that their intention is to set up a call with one another.
 
 In Matrix, calls are to rooms rather than users (even if those rooms may only
-contain one other user) so we consider calls which are to the same room.
-
-The rules for dealing with such a situation are as follows:
+contain one other user) so we consider calls which are to the same room. The
+rules for dealing with such a situation are as follows:
 
  - If an invite to a room is received whilst the client is preparing to send an
    invite to the same room, the client should cancel its outgoing call and
diff --git a/templating/matrix_templates/units.py b/templating/matrix_templates/units.py
index 4b8127ae..3a8825ae 100644
--- a/templating/matrix_templates/units.py
+++ b/templating/matrix_templates/units.py
@@ -361,8 +361,8 @@ class MatrixUnits(Units):
 
                 # add typeof
                 base_defs = {
-                    "core#/definitions/room_event": "Message Event",
-                    "core#/definitions/state_event": "State Event"
+                    "core/room_event.json": "Message Event",
+                    "core/state_event.json": "State Event"
                 }
                 if type(json_schema.get("allOf")) == list:
                     schema["typeof"] = base_defs.get(
@@ -399,7 +399,6 @@ class MatrixUnits(Units):
                         "`m.room.message msgtypes`_."
                     )
 
-
                 # Assign state key info if it has some
                 if schema["typeof"] == "State Event":
                     skey_desc = Units.prop(