fixup! squash/drop: Remove top-level schema namespace

Update docs talking about Specifications not having an explicit version,
now that they do (though it still doesn't get sent over the wire).

Signed-off-by: David Feltell <[email protected]>

Author: feltech

examples/working_with_trait_versions.ipynb

@@ -173,21 +173,19 @@
    "execution_count": 4
   },
   {
+   "metadata": {},
    "cell_type": "markdown",
    "source": [
     "### Specifications\n",
     "\n",
     "Specifications are a way to document well-known sets of traits that categorize entities, relationships, locales, or policies. Agreement on these as an industry is crucial for effective interop.\n",
     "\n",
-    "However, they do not have an independent version - their version is implicit in the (versioned) traits that they compose. A major consequence of this is that no specification version is embedded in the data itself.\n",
+    "However, no specification version is embedded in the data itself. The data sent between host and manager only contains the versions of the composite traits. Detecting that some trait data satisfies a specification therefore requires a try-and-see approach, checking the data against the specification's trait set.\n",
     "\n",
     "If the raison d'être of specifications is a way to have an industry-standard collection of trait sets, then is the exact version of those traits really important? On the assumption that a new version of a trait doesn't fundamentally change its meaning (otherwise it would be an entirely new trait), then it's reasonable to say that specifications are trait version agnostic.\n",
     "\n",
     "So specifications are invaluable as documentation of common trait sets. However, the auto-generateed `Specification` view classes should be used with caution: using a specification view class to categorize an entity may lead to unexpected false negatives when the trait versions do not line up.\n"
    ],
-   "metadata": {
-    "collapsed": false
-   },
    "id": "ab4dde470a3808d4"
   },
   {