Documentation fixes (#2108)

* Fix messsage -> message

* Fix atribute -> attribute

* Update links to the Model State documentation

* Fix Ouput Widget doc link

Fixes #2106

Author: jtpio

docs/source/examples/Widget List.ipynb

@@ -1291,7 +1291,7 @@
    "source": [
     "## Output\n",
     "\n",
-    "The `Output` widget can capture and display stdout, stderr and [rich output generated by IPython](http://ipython.readthedocs.io/en/stable/api/generated/IPython.display.html#module-IPython.display). For detailed documentation, see the [output widget examples](/examples/Output Widget.html)."
+    "The `Output` widget can capture and display stdout, stderr and [rich output generated by IPython](http://ipython.readthedocs.io/en/stable/api/generated/IPython.display.html#module-IPython.display). For detailed documentation, see the [output widget examples](https://ipywidgets.readthedocs.io/en/latest/examples/Output Widget.html)."
    ]
   },
   {

docs/source/examples/Widget Low Level.ipynb

@@ -326,7 +326,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "After the Widget has been constructed, it can be displayed.  Calling `display(widgetinstance)` causes a specially named repr method in the widget to run.  This method sends a message to the front-end that tells the front-end to construct and display a widget view.  The message is in response to the original code execution message, and the original message’s GUID is stored in the new message’s header.  When the front-end receives the message, it uses the original messsage’s GUID to determine what cell the new view should belong to.  Then, the view is created, using the WidgetView class specified in the WidgetModel’s state.  The same require.js method is used to load the view class.  Once the class is loaded, an instance of it is constructed, displayed in the right cell, and registers listeners for changes of the model."
+    "After the Widget has been constructed, it can be displayed.  Calling `display(widgetinstance)` causes a specially named repr method in the widget to run.  This method sends a message to the front-end that tells the front-end to construct and display a widget view.  The message is in response to the original code execution message, and the original message’s GUID is stored in the new message’s header.  When the front-end receives the message, it uses the original message’s GUID to determine what cell the new view should belong to.  Then, the view is created, using the WidgetView class specified in the WidgetModel’s state.  The same require.js method is used to load the view class.  Once the class is loaded, an instance of it is constructed, displayed in the right cell, and registers listeners for changes of the model."
    ]
   },
   {

docs/source/examples/Widget Styling.ipynb

@@ -737,7 +737,7 @@
     "While the `layout` attribute only exposes layout-related CSS properties for the top-level DOM element of widgets, the  \n",
     "`style` attribute is used to expose non-layout related styling attributes of widgets.\n",
     "\n",
-    "However, the properties of the `style` atribute are specific to each widget type."
+    "However, the properties of the `style` attribute are specific to each widget type."
    ]
   },
   {

packages/schema/messages.md

@@ -91,7 +91,7 @@ Symmetrically, when instantiating a widget in the kernel, the kernel widgets lib
 }
 ```
 
-The type of widget to be instantiated in the frontend is determined by the `_model_name`, `_model_module` and `_model_module_version` keys in the state, which respectively stand for the name of the class that must be instantiated in the frontend, the JavaScript module where this class is defined, and a semver range for that module. See the [Model State](modelstate.md) documentation for the serialized state for core Jupyter widgets.
+The type of widget to be instantiated in the frontend is determined by the `_model_name`, `_model_module` and `_model_module_version` keys in the state, which respectively stand for the name of the class that must be instantiated in the frontend, the JavaScript module where this class is defined, and a semver range for that module. See the [Model State](jupyterwidgetmodels.v6.md) documentation for the serialized state for core Jupyter widgets.
 
 ### State synchronization
 
@@ -116,7 +116,7 @@ The `data.state` value is a dictionary of widget state keys and values that can
 
 Comm messages for state synchronization may contain binary buffers. The optional `data.buffers` value contains a list of keys corresponding to the binary buffers. For example, if `data.buffers` is `['x', 'y']`, then the first binary buffer is the value of the `'x'` state attribute and the second binary buffer is the value of the `'y'` state attribute.
 
-See the [Model state](modelstate.md) documentation for the attributes of core Jupyter widgets.
+See the [Model state](jupyterwidgetmodels.v6.md) documentation for the attributes of core Jupyter widgets.
 
 #### Synchronizing from frontend to kernel: `backbone`
 
@@ -269,7 +269,7 @@ The `data.state` value is a dictionary of widget state keys and values that can
 
 Comm messages for state synchronization may contain binary buffers. The `data.buffer_paths` value contains a list of 'paths' in the `data.state` object corresponding to the binary buffers. For example, if `data.buffer_paths` is `[['x'], ['y', 'z', 0]]`, then the first binary buffer is the value of the `data.state['x']` attribute and the second binary buffer is the value of the `data.state['y']['z'][0]` state attribute. A path representing a list value (i.e., last index of the path is an integer) will be `null` in `data.state`, and a path representing a dictionary key (i.e., last index of the path is a string) will not exist in `data.state`.
 
-See the [Model State](modelstate.md) documentation for the serialized state for core Jupyter widgets.
+See the [Model State](jupyterwidgetmodels.latest.md) documentation for the serialized state for core Jupyter widgets.
 
 ### State synchronization
 
@@ -290,7 +290,7 @@ When a widget's state changes in either the kernel or the frontend, the changed
 
 The `data.state` and `data.buffer_paths` values are the same as in the `comm_open` case.
 
-See the [Model state](modelstate.md) documentation for the attributes of core Jupyter widgets.
+See the [Model state](jupyterwidgetmodels.latest.md) documentation for the attributes of core Jupyter widgets.
 
 #### State requests: `request_state`