Updated Proposal: application schema coordination and versioning (markdown)

Proposal:-application-schema-coordination-and-versioning.md

@@ -22,10 +22,14 @@ One is "head in the sand". If your vocabulary doesn't change, or only grows new
 
 If your vocabulary changes, however, you will need a way to evolve it using the primitives available to you: altering attributes, renaming idents, and retracting and transacting schema fragments and data datoms.
 
-One approach to doing so is to track some kind of version identifier outside of the datom store. This is straightforward, but prone to error when the datom store and external version identifier don't change together (*e.g.*, when a database file is restored from backup).
+The first step is to decide *when* to evolve the schema.
+
+One practical approach to doing so is to track some kind of version identifier outside of the datom store. This is straightforward, but prone to error when the datom store and external version identifier don't change together (*e.g.*, when a database file is restored from backup).
 
 Another approach is to track the version identifier inside the datom store itself. This is more foolproof, but requires vocabulary for versioning.
 
+An application might also directly inspect the schema to come up with a migration plan, but this is likely to be error prone and inefficient.
+
 
 ## Multiple applications with disjoint schema
 
@@ -35,6 +39,8 @@ These applications can entirely pretend that the other application doesn't exist
 [:find ?x :in $ :where [(fulltext $ :any "some text") [[?x]]]]
 ```
 
+This should be viewed as a strength!
+
 
 ## Multiple applications with read-only interrelationships
 
@@ -60,11 +66,11 @@ Schema names and versions are added or updated as schema fragments are transacte
 
 Applications should ensure that no attribute is present in more than one schema fragment; an error will be thrown in that case.
 
-These pieces of metadata are themselves stored in the datom store. Applications can listen for changes in order to pick up new vocabulary added by other applications accessing the same datom store.
+These pieces of metadata are themselves stored in the datom store. Applications can listen for changes. In response to changes, they can pick up new vocabulary added by other applications.
 
 The API exposes operations:
 
-- Check whether this schema fragment is at this version. This allows for read-only applications to adjust their behavior accordingly.
+- Check whether this schema fragment name is at this version. This allows for read-only applications to adjust their behavior accordingly.
 - Ensure that this fragment is at this version; if not:
   - Create it if needed.
   - Optionally, attempt to automatically transact the difference between the two schema fragments. For example, an attribute with `:db/cardinality :db.cardinality/one` can always be safely altered to `:db.cardinality/many`.