Specs: default exports to {} rather than document, since it makes writing modules saner

sky/specs/modules.md

 Sky Module System
 =================
 
 This document describes the Sky module system.
 
 Overview
 --------
 
 The Sky module system is based on the ``import`` element. In its
 most basic form, you import a module as follows:
@@ skipping 17 matching lines @@
 Module API
 ----------
 
 Within a script in a module, the ``module`` identifier is bound to
 the [``Module`` object](apis.md) that represents the module.
 
 ### Exporting values ###
 
 A module can export a value by assigning the ``exports`` property of
 its ``Module`` object. By default, the ``exports`` property of a
-``Module`` is its ``Document`` object, so that a script-less
-import is still useful (it exposes its contents, e.g. templates that
-the import might have been written to provide).
+``Module`` is an empty Object. Properties can be added to the object,
+or, it can be set to an entirely different object; for example, it
+could be set to the module's Document itself, in case the point of the
+module is to expose some ``template`` elements.
 
 ### Exporting element definitions ###
 
 When importing a module into another, Sky looks at the properties on
 the imported module's ``exports`` value, and for each property that is
 an element constructor (generated by ``registerElement()``), it adds
 an element to the importee's element registry.
 
  
 Naming modules
@@ skipping 17 matching lines @@
 Where ``name_1`` through ``name_n`` are the names bound to the
 various named imports in the script element's document,
 ``source_code`` is the text content of the script element,
 ``source_module`` is the ``Module`` object of the script element's
 module, and ``value_1`` through ``value_n`` are the values
 exported by the various named imports in the script element's
 document.
 
 When an import fails to load, the ``as`` name for the import gets
 bound to ``undefined``.