home.md

@@ -28,19 +28,19 @@ However an important consideration is that none of these are in scope for this t
 
 * In general, any "semantic" interpretation of ad-hoc (local) names in the Word document. For example a segment marked as style "Italic" may be so marked in the HTML (as a `<span class="Italic">`), but not marked as HTML `i` or represented as italic in any other way.
 
-None of these rules are absolute. In particular because it will be difficult to be both comprehensive and succinct (economical), the particulars of the target format (as respects element types, attribute values etc.) are probably best defined "under load" (that is, in use). We like HTML because it is a vernacular and developers know what to expect from it -- so it gives us some (broad) boundaries going forward.
+None of these rules are absolute. In particular because it will be difficult to be both comprehensive and succinct (economical), the particulars of the target format (as respects element types, attribute values etc.) are probably best designed in use. HTML tagging works as a baseline because it is a vernacular and developers know what to expect from it -- so it gives us some (broad) boundaries going forward.
 
-Development of a formal spec for such a format is an item tbd. For now, we intend to "produce pudding" that can be proven by eating it.
+Development of a formal spec for such a format is an item tbd. For now, we intend to produce "good pudding" that can be proven by eating it.
 
-"HTML slops" or HTML soup is what we call the output - it is nutritious, but messy.
+"HTML slops" or HTML soup is what we call the output - it is messy, but nutritious. Broadly speaking, it should be considered a (fairly weak) form of HTML or HTML5, using XML syntax (albeit an empty XML prologue) making it amenable to both XML and HTML parsers.
 
 ## Iterative development model
 
-Since many of the particular requirements can only be defined in use, project feedback is essential to further development of these stylesheets.
+Since many of the particular requirements for data capture and representation can only be defined in use, project feedback is essential to further development of these stylesheets.
 
 For the time being this will involve old-fashioned comparisons between Word source data and HTML produced by the XSLT and as exposed in PubSweet, and reporting lapses and possible discrepancies.
 
-We hope and intend to ride a comfortable slope, whereon the time required by an XSLT developer to process a single (set of) Word documents for PubSweet drops to less and less, until it is nothing at all, unless you include configuration-level stuff or tweaks performed routinely by team members with XSLT (or other) skills.
+As the system matures it should require less and less time from an XSLT developer to process a single (set of) Word documents for PubSweet. A sustainable system may permit configuration or tweaks to performed routinely by team members with XSLT (or other) skills, but it should not require deep XSLT-fu to keep it running or extend to new cases.
 
 Since there is much to be done to get to that point, this means being vigilant for opportunities for improvement.