#
#
# patch "wiki/BasicIoFormalization.mdwn"
#  from [e5dc640acf39be3bb668c1f7107566e2d5b08c5c]
#    to [491235c6230dc6e2464f1e7186a12e0261ec40ea]
# 
# patch "wiki/CertCleanup.mdwn"
#  from [b98d0f049ab845bf865ddfa6f54e9b9635c6eb3f]
#    to [6560cd1b3c58a73f748282a2ccc735675c18d568]
#
============================================================
--- wiki/BasicIoFormalization.mdwn	e5dc640acf39be3bb668c1f7107566e2d5b08c5c
+++ wiki/BasicIoFormalization.mdwn	491235c6230dc6e2464f1e7186a12e0261ec40ea
@@ -1,9 +1,7 @@
-[[!tag migration-auto]]
+[[!tag migration-done]]
 
-There's some debate on what the formal definition of basic_io should be, and in particular whether stanzas and lines should be first class items, or it should continue to treat all whitespace as identical, except with one special normalized form.
+There's [some debate](http://colabti.org/irclogger/irclogger_log/monotone?date=2005-11-25,Fri&sel=117#l194) on what the formal definition of basic_io should be, and in particular whether stanzas and lines should be first class items, or it should continue to treat all whitespace as identical, except with one special normalized form.
 
-http://colabti.de/irclogger/irclogger_log/monotone?date=2005-11-25,Fri&sel=117#l194
-
 Attempting to tame this discussion a bit...
 
 # Concrete issues
@@ -15,16 +13,18 @@ Arguments to make stanzas/lines first cl
 # Fuzzier stuff
 
 Arguments to make stanzas/lines first class items:
-  * It seems unnecessarily confusing to have two somewhat different formats -- "basic_io" and "normalized basic_io"; especially since they're not clearly distinguished.
-  * It is nice if de facto and de jure standards line up.  (The field of "usability" is basically the art/science of making this happen.)  They don't right now; no-one who has simply been exposed to basic_io stuff has any idea that stanzas are insignificant.
+
+  * It seems unnecessarily confusing to have two somewhat different formats -- "basic\_io" and "normalized basic\_io"; especially since they're not clearly distinguished.
+  * It is nice if _de facto_ and _de jure_ standards line up.  (The field of "usability" is basically the art/science of making this happen.)  They don't right now; no-one who has simply been exposed to basic_io stuff has any idea that stanzas are insignificant.
   * related: people will script monotone; they won't read the formal docs first
 
 Arguments to leave stanzas/lines as epiphenomena:
+
   * meaningful whitespace is a generally bad idea.
         <graydon_> error cases with whitespace-sensitivity: pasting two stanzas together and forgetting to insert a newline. pasting two files together, inserting one extra newline, accidentally creating a "null stanza". wrapping. crlf conversion.
      also, whitespace mangling (though "" blocks can also be mangled).
+
 # Empirical questions
 
+ * Is one formalism easier to code up a quick parser for?
+ * Does one formalism lead to a parser that's easier to hack up a quick program around?
-Is one formalism easier to code up a quick parser for?
-
-Does one formalism lead to a parser that's easier to hack up a quick program around?
============================================================
--- wiki/CertCleanup.mdwn	b98d0f049ab845bf865ddfa6f54e9b9635c6eb3f
+++ wiki/CertCleanup.mdwn	6560cd1b3c58a73f748282a2ccc735675c18d568
@@ -1,8 +1,9 @@
-[[!tag migration-auto]]
+[[!tag migration-done]]
 
 While we're doing [[VersionedPolicy]], we probably want to take the opportunity to clean up some stuff about how we do certs.
 
 Some thoughts:
+
   * should we namespace certs, like we do attrs?  I.e., have cert names like `mtn:branch`, `mtn:author`, etc.?
   * [[BranchRenaming]] is hard, because literal branch names are tied too closely to branch certs, and changing literal cert values is hard (as noted in [[UsingCerts]]).  The fix is not to allow certs to be changed, but to abstract branch names from cert values using [[VersionedPolicy]].
   * certs should have ids, like other objects -- so that we can refer to them when necessary.  (This is useful for packet commands, for stating which certs should be trusted, etc.)