diff --git a/tutorial/PRODUCE-TUTORIAL-TOC.xpl b/tutorial/PRODUCE-TUTORIAL-TOC.xpl
index fe331695..1956de8b 100644
--- a/tutorial/PRODUCE-TUTORIAL-TOC.xpl
+++ b/tutorial/PRODUCE-TUTORIAL-TOC.xpl
@@ -22,9 +22,10 @@
       <p:directory-list path="source/{ $lesson_key }" max-depth="unbounded" include-filter="_src\.html$"/>
       <p:add-attribute attribute-name="position" attribute-value="{p:iteration-position()}"/>      
 
+      <p:label-elements match="c:file" attribute="path" label="ancestor-or-self::*/@xml:base => string-join('')"/>
    <!-- is there a better way to annotate a directory list with full paths?
         or: make a step out of this and import it -->
-      <p:xslt>
+      <!--<p:xslt>
          <p:with-input port="stylesheet">
             <p:inline expand-text="false">
                <xsl:stylesheet version="3.0">
@@ -39,13 +40,16 @@
                </xsl:stylesheet>
             </p:inline>
          </p:with-input>
-      </p:xslt>
+      </p:xslt>-->
       <p:viewport match="c:file">
          <p:variable name="path" select="/*/@path"/>
          <p:load href="{$path}" message="[PRODUCE-TUTORIAL-TOC] Loading {$path}"/>
+         <p:variable name="track" select="/*/*/@data-track"/>
+         
          <p:filter select="descendant::h1[1]"/>
          <p:rename new-name="file"/>
          <p:add-attribute attribute-name="href" attribute-value="{ replace($path,'.*/','') => replace('_src\.html$','.md') }"/>
+         <p:add-attribute attribute-name="track" attribute-value="{ $track }"/>
       </p:viewport>
    </p:for-each>
    
@@ -66,7 +70,7 @@
                </xsl:template>
                <xsl:template match="directory" expand-text="true">
                   <div>
-                     <h3>Lesson unit { format-number(@position,'01') }</h3>
+                     <h3>Lesson set { format-number(@position,'01') } - { @name }</h3>
                      <ul>
                         <xsl:apply-templates/>
                      </ul>
@@ -80,7 +84,8 @@
                <xsl:template match="file" mode="link">
                   <a href="Lesson{ format-number(parent::*/@position,'01') }/{@href}">
                      <xsl:apply-templates/>
-                  </a>
+                  </a>                  
+                  <xsl:text expand-text="true"> ({ upper-case(@track) })</xsl:text>
                </xsl:template>
             </xsl:stylesheet>
          </p:inline>
diff --git a/tutorial/lesson-plan.xml b/tutorial/lesson-plan.xml
index ca6575a2..1db6ec6a 100644
--- a/tutorial/lesson-plan.xml
+++ b/tutorial/lesson-plan.xml
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <LESSON_PLAN>
-   <Lesson key="setup"/>
-   <Lesson key="unpack"/>            
+   <Lesson key="acquire"/>
+   <Lesson key="walkthrough"/>            
    <Lesson key="oscal-convert"/>
    <Lesson key="practicum"/>            
    <!--
diff --git a/tutorial/outline.md b/tutorial/outline.md
index 50620009..6e659048 100644
--- a/tutorial/outline.md
+++ b/tutorial/outline.md
@@ -68,6 +68,7 @@ For convenience, each lesson unit focuses on a project (as noted).
 
 ### Equipment
 
+
 You will be happy to have a developer's or data analyst's setup:
 
 - Command line with bash or Windows (cmd/Powershell)
diff --git a/tutorial/sequence/Lesson01/setup_101.md b/tutorial/sequence/Lesson01/acquire_101.md
similarity index 92%
rename from tutorial/sequence/Lesson01/setup_101.md
rename to tutorial/sequence/Lesson01/acquire_101.md
index 9d2e3f58..444c62fc 100644
--- a/tutorial/sequence/Lesson01/setup_101.md
+++ b/tutorial/sequence/Lesson01/acquire_101.md
@@ -1,6 +1,6 @@
 
 
-> *Warning:* this Markdown file will be rewritten under continuous deployment (CD): edit the source in [/tutorial/source/setup/setup_101_src.html](../../../tutorial/source/setup/setup_101_src.html).
+> *Warning:* this Markdown file will be rewritten under continuous deployment (CD): edit the source in [/tutorial/source/acquire/acquire_101_src.html](../../../tutorial/source/acquire/acquire_101_src.html).
 > 
 > Save this file elsewhere to create a persistent copy (for example, for purposes of annotation).
 
@@ -67,12 +67,12 @@ Since almost any pipeline will use XSLT and since we do use the latest version (
 
 The top-level README and setup notes also describe testing your installation. Do this next.
 
-You know things are working in your XProc when either or both of two things are happening:
+You know things are working in your XProc when two things are happening:
 
 * On the console, notifications show up with reassuring messages announcing progress
-* When you expect files to be produced, they appear, or are updated, as expected
+* When you expect files to be produced for you, they appear, or are updated, as expected
 
-Both of those will occur with this lesson. The files produced by downloading scripts are written into the project `lib` directory, as documented. Refresh or restore by deleting the downloaded files and running the pipelines to acquire them again.
+Both of those will occur with this lesson. The files produced by downloading pipelines are written into the project `lib` directory, as documented. Refresh or restore by deleting the downloaded files and running the pipelines to acquire them again.
 
 Note: you need a live Internet connection for your `http` requests to go through.
 
@@ -82,13 +82,13 @@ When you can run all the smoke tests without ugly tracebacks, this lesson is com
 
 Within this project as a whole, and within its subprojects, everything is done with XProc 3.0, meaning everything can be done using a single script, which invokes an XProc processor to read and execute a pipeline. This simplicity is at the center of the argument for XProc. 
 
-Effectively (and much more could be said about the processing stack, dependency management and so forth) what this means is that XProc offers the user and the developer (in either or both roles) with focused and concentrated points of control or points of adjustment. In the field – where software is deployed and used – things almost never just &ldquo;drop in&rdquo;. User interfaces, APIs, dependencies and platform quirks: all these constrain what users can do, and even developers are rarely free to just mess around, as it might be thought of.
+Effectively (and much more could be said about the processing stack, dependency management and so forth) what this means is that XProc offers the user and the developer (in either or both roles) with focused and concentrated points of control or points of adjustment. In the field – where software is deployed and used – things almost never just &ldquo;drop in&rdquo;. User interfaces, APIs, dependencies and platform quirks: all these constrain what users can do, and even developers are rarely free to experiment and explore.
 
 To the extent this is the case, this project only works if things are actually simple enough to pick up, use, learn and adapt.
 
 `xp3.sh` and `xp3.bat` represent attempts at this. Each of them (on its execution platform) enables a user to run, without further configuration, the [Morgana XProcIIIse](https://www.xml-project.com/morganaxproc-iiise.html) processor on any XProc 3.0 pipeline, assuming the appropriate platform for each (`bash` in the case of the shell script, Windows batch command syntax for the `bat` file). Other platforms supporting Java (and hence Morgana with its libraries) could be provided with similar scripts.
 
-Such a script itself must be &ldquo;vanilla&rdquo; and generic: it simply invokes the processor with the designated pipeline, and stands back. The logic of operations is entirely encapsulated in the XProc pipeline designated. XProc 3.0 is both scalable and flexible enough to open a wide range of possibilities for data processing, both XML-based and using other formats such as JSON and plain text. It is the intent of this project not to explore and map this space – which is vast – but to show off enough XProc and related logic (XSLT, XSpec) to show how this exploration can be done. We are an outfitter at the beginning of what we hope will be a long and profitable voyage.
+Such a script itself must be &ldquo;vanilla&rdquo; and generic: it simply invokes the processor with the designated pipeline, and stands back. The logic of operations is entirely encapsulated in the XProc pipeline designated. XProc 3.0 is both scalable and flexible enough to open a wide range of possibilities for data processing, both XML-based and using other formats such as JSON and plain text. It is the intent of this project not to explore and map this space – which is vast – but to show off enough XProc and related logic (XSLT, XSpec) to show how this exploration can be done. We are an outfitter at the beginning of what we hope will be many profitable voyages to places we have never been.
 
 ### Tweaks
 
diff --git a/tutorial/sequence/Lesson01/setup_102.md b/tutorial/sequence/Lesson01/acquire_102.md
similarity index 90%
rename from tutorial/sequence/Lesson01/setup_102.md
rename to tutorial/sequence/Lesson01/acquire_102.md
index 4028aa4c..22a3c246 100644
--- a/tutorial/sequence/Lesson01/setup_102.md
+++ b/tutorial/sequence/Lesson01/acquire_102.md
@@ -1,6 +1,6 @@
 
 
-> *Warning:* this Markdown file will be rewritten under continuous deployment (CD): edit the source in [/tutorial/source/setup/setup_102_src.html](../../../tutorial/source/setup/setup_102_src.html).
+> *Warning:* this Markdown file will be rewritten under continuous deployment (CD): edit the source in [/tutorial/source/acquire/acquire_102_src.html](../../../tutorial/source/acquire/acquire_102_src.html).
 > 
 > Save this file elsewhere to create a persistent copy (for example, for purposes of annotation).
 
@@ -33,20 +33,20 @@ The key to understanding both groups is to know that once the initial [Setup
 
 Specifically, the pipelines can acquire resources from the Internet, save them locally, and perform unarchiving (unzipping). Having been downloaded, each library provides software that the pipeline engine (Morgana) can use to do more.
 
-Accordingly, the first group of pipelines (in the [lib](../../../lib/readme.md) directory has a single purpose, namely (together and separately) to download software for Morgana.
+Accordingly, the first group of pipelines (in the [lib](../../../lib/readme.md) directory has a single purpose, namely (together and separately) to download software to augment Morgana's feature set.
 
 * [lib/GRAB-SAXON.xpl](../../../lib/GRAB-SAXON.xpl)
 * [lib/GRAB-SCHXSLT.xpl](../../../lib/GRAB-SCHXSLT.xpl)
 * [lib/GRAB-XSPEC.xpl](../../../lib/GRAB-XSPEC.xpl)
 
-The second group of pipelines also has a single purpose, namely to exercise and test the capabilities provided by the software downloaded by the first group.
+Pipelines in a second group work similarly in that each one exercises and tests capabilities provided by software downloaded by a member of the first group.
 
 * [smoketest/TEST-XPROC3.xpl](../../../smoketest/TEST-XPROC3.xpl) tests MorganaXProc-III
 * [smoketest/TEST-XSLT.xpl](../../../smoketest/TEST-XSLT.xpl) tests Saxon
 * [smoketest/TEST-SCHEMATRON.xpl](../../../smoketest/TEST-SCHEMATRON.xpl) tests SchXSLT
 * [smoketest/TEST-XSPEC.xpl](../../../smoketest/TEST-XSPEC.xpl) tests XSpec
 
-Take a look at these files. It may be helpful to envision the XML syntax as a set of nested frames with labels and connectors.
+Take a look at these files. It may be helpful (for those getting used to it) to envision the XML syntax as a set of nested frames with labels and connectors.
 
 Try more than one way of looking at the XProc source code: in the Github repository, on your file system, in a plain text editor, in an XML editor.
 
diff --git a/tutorial/sequence/Lesson01/setup_599.md b/tutorial/sequence/Lesson01/acquire_599.md
similarity index 51%
rename from tutorial/sequence/Lesson01/setup_599.md
rename to tutorial/sequence/Lesson01/acquire_599.md
index 5387f63f..569024a0 100644
--- a/tutorial/sequence/Lesson01/setup_599.md
+++ b/tutorial/sequence/Lesson01/acquire_599.md
@@ -1,6 +1,6 @@
 
 
-> *Warning:* this Markdown file will be rewritten under continuous deployment (CD): edit the source in [/tutorial/source/setup/setup_599_src.html](../../../tutorial/source/setup/setup_599_src.html).
+> *Warning:* this Markdown file will be rewritten under continuous deployment (CD): edit the source in [/tutorial/source/acquire/acquire_599_src.html](../../../tutorial/source/acquire/acquire_599_src.html).
 > 
 > Save this file elsewhere to create a persistent copy (for example, for purposes of annotation).
 
@@ -15,3 +15,11 @@ MorganaXProc-III is implemented in Scala, and Saxon is built in Java, but otherw
 Which is it, and what are the determining variables that tell you XProc is a good fit? How much of this is due to the high-level, abstracted nature of [4GLs](https://en.wikipedia.org/wiki/Fourth-generation_programming_language) including both XSLT 3.1 and XProc 3.0? Prior experience with XML-based systems and the problem domains in which they work well is probably a factor. How much are the impediments technical, and how much are they due to culture?
 
 The next lesson unit includes more information on where to learn about XProc and how to become familiar not only with its uses in connection with OSCAL, but in general.
+
+## Declarative markup in action
+
+Considerable care is taken in developing these demonstrations to see to it that the technologies on which we depend, notably XProc and XSLT but not limited to these, are both nominally and actually conformant to externally specified standard technologies, i.e. XProc and XSLT respectively (as well as others), and reliant to the greatest possible extent on well-documented and accessible runtimes.
+
+It is a tall order to ask that any code base should be both easy to integrate and use with others, and at the same time, functionally complete and self-sufficient. Of these two, we are lucky to get one. Because the world is complex, we are always throwing in one or another new dependency, along with new rule sets. Here, we work by making everything transparent as possible (so nothing is downloaded behind the scenes, for example) while also documenting as thoroughly as we can, including with code comments.
+
+Can any code base be self-explanatory in any meaningful sense? Doubtful. But one can try and leave tracks and markers, at least. 
diff --git a/tutorial/sequence/Lesson02/unpack_101.md b/tutorial/sequence/Lesson02/walkthrough_101.md
similarity index 63%
rename from tutorial/sequence/Lesson02/unpack_101.md
rename to tutorial/sequence/Lesson02/walkthrough_101.md
index ff6edd1f..dadfc4df 100644
--- a/tutorial/sequence/Lesson02/unpack_101.md
+++ b/tutorial/sequence/Lesson02/walkthrough_101.md
@@ -1,6 +1,6 @@
 
 
-> *Warning:* this Markdown file will be rewritten under continuous deployment (CD): edit the source in [/tutorial/source/unpack/unpack_101_src.html](../../../tutorial/source/unpack/unpack_101_src.html).
+> *Warning:* this Markdown file will be rewritten under continuous deployment (CD): edit the source in [/tutorial/source/walkthrough/walkthrough_101_src.html](../../../tutorial/source/walkthrough/walkthrough_101_src.html).
 > 
 > Save this file elsewhere to create a persistent copy (for example, for purposes of annotation).
 
@@ -13,7 +13,7 @@
 
 ## Resources
 
-This lesson discusses, in more depth, the same pipelines you ran in setup: [Setup 101](../setup/setup_101.md), in particular [the smoke test pipelines](../../../smoketest/readme.md).
+This lesson discusses, in more depth, the same pipelines you ran in setup: [Setup 101](../acquire/acquire_101.md), in particular [the smoke test pipelines](../../../smoketest/readme.md).
 
 Also, this lesson discusses a pipeline used for producing this tutorial: [PRODUCE-PROJECTS-ELEMENTLIST.xpl](../../PRODUCE-PROJECTS-ELEMENTLIST.xpl) generates an [index to XProc in this repository](../../sequence/element-directory.md)
 
@@ -25,11 +25,20 @@ The last section of this lesson unit describes more reference materials as well.
 
 ## Prerequisites
 
-Same as [Setup 101](../setup/setup_101.md).
+No prerequisites. The commentary assumes, however:
+
+* You have run the acquisition, setup and test pipelines [described in the first lesson set](../acquire/acquire_101.md), or you are willing to pretend you have done so for our purposes here
+* You have some prior experience with either XML technologies, web publishing technologies, data modeling and data exchange, or (again) you are open to learning or at least thinking about it
+
+If you fall into neither of these categories – welcome, and congratulations on your perseverence at least. These pages are certainly available to be read and referenced even if you are not running any of the software: as part of the resource provided (repository), they are open to anyone who finds them to be useful, including for specialized purposes.
+
+So you are also welcome to read what follows if this is your first look at XProc, or if you are not after the runtime, only the ideas, or if you have some other use in mind (such as perhaps testing an XProc engine?).
+
+If you fall into this category, however, you should (one last time!) consider running some of the code after all. You might be surprised at how easy and not-so-scary it really is.
 
 ## A closer look
 
-If you have completed [Setup 102](../setup/setup_101.md) you have already inspected the [lib](../../../lib/readme.md) and [smoketest](../../../smoketest/readme.md) folders, and run pipelines you have found there. If you haven't, now is the moment to catch up.
+If you have completed [Acquire 102](../acquire/acquire_101.md) you have already inspected the [lib](../../../lib/readme.md) and [smoketest](../../../smoketest/readme.md) folders, and run pipelines you have found there. If you haven't, now is a moment to catch up. Even if you have decided not to install any software, please look at the pipelines we are using for the purpose here.
 
 Routine code inspection can also be done on Github as well (not a bad idea in any case), not just in a copy of the distribution.
 
@@ -43,7 +52,7 @@ Essentially, these all replicate and capture the work a developer must do to ide
 
 The second group of pipelines is a bit more interesting. Each of the utilities provided for in packages just downloaded is tested by running a smoke test.
 
-Each smoke test performs a minor task, serving as a &ldquo;smoke test&rdquo; inasmuch as its only aim is to determine whether a simple representative process completes successfully. (When we plug in the board, can we see and smell smoke?)
+Each smoke test performs a minor task, serving as a &ldquo;smoke test&rdquo; inasmuch as its only aim is to determine whether a simple representative process completes successfully. (When we plug the unit in and switch on the power, can we see and smell smoke?)
 
 * [smoketest/TEST-XPROC3.xpl](../../../smoketest/TEST-XPROC3.xpl) amounts to an XProc &ldquo;Hello World&rdquo;. In that spirit, feel free to write your own version.
 * [smoketest/TEST-XSLT.xpl](../../../smoketest/TEST-XSLT.xpl) tests Saxon, an XSLT/XQuery transformation engine. XSLT and XQuery are related technologies (different languages, same data model) developed with XML processing in mind, but in recent years generalized to a wider range of data structures.
@@ -56,7 +65,7 @@ At the same time, common foundations make it possible to learn these technologie
 
 ## Walkthrough
 
-Each of the test pipelines exercises a simple sequence of operations. Open the XSpec file in an editor or viewer where you can see the tags.
+Each of the test pipelines exercises a simple sequence of operations. Open any XProc file in an editor or viewer where you can see the tags.
 
 ### TEST-XPROC3
 
@@ -101,32 +110,40 @@ An XSpec instance (or &ldquo;document&rdquo;) defines a set of tests for a trans
 * `p:for-each` – defines a step or sequence of steps to be applied to each input, separately.
 * `p:identity` – simply passes through the previous step's result. While this is a &ldquo;no-op&rdquo; in the XProc itself, it provides an occasion for a message to help trace the XProc execution.
 
-[The next lesson](unpack_102.md) offers more detail about this pipeline.
+[The next lesson](walkthrough_102.md) offers more detail about this pipeline.
 
 ## A not-so-simple pipeline
 
-These simple pipelines show how useful things can be done simply, while the pipeline architecture allows for great flexibility.
+**tl/dr** - examine the Markdown file presenting [XProc                Element directory](../../sequence/element-directory.md). It is generated by [a             pipeline](../../PRODUCE-PROJECTS-ELEMENTLIST.xpl). Examine that pipeline to see XProc with real-world complexity.
+
+The simple pipelines examined so far show how useful things can be done simply, while the pipeline architecture allows for great flexibility.
 
 Simplicity and flexibility together enable complexity. Once it is factored out, a complex operation can be managed and deployed just like a simple one, with its internal complexities masked by a simple and predictable interface.
 
-Next, take a look at a more complex example, the prototype pipeline [PRODUCE-PROJECTS-ELEMENTLIST.xpl](../../PRODUCE-PROJECTS-ELEMENTLIST.xpl). Like the setup and smoke-test pipelines, this is a standalone pipeline that acquires inputs and produces results and writes those results to the file system. The output it generates is stored as [element-directory.md](../../sequence/element-directory.md), a Markdown file (find the `p:store` step).
+One other important feature of XProc must be kept in mind: so far at least, it is all XML. Not yet haven't looked at any real-world problems, we haven't seen pipelines that work directly with XML data yet, much, except in the most rudimentary form (the smoke tests). But most of the time that is what XProc is for. Moreover, XProc is itself in XML syntax, which makes it possible to work XProc with XProc. XProc folding over on itself. Even short of of dynamically generating and executing XProc (and yes that can be done), the common ground of XML format means that with XProc working XML tools, XML and its related ecosystem (most significantl but not only XPath) is always available as a force magnifier or power tool, something we can put to work again and again. In XProc, errors are reported in XML. So we can capture, aggregate and index error messages in XProc. In XProc, a directory file listing is provided in XML. So we have a ready way to present views of file systems – the XML shows all the names and structures – as well as analyze them and access the files in them. Etc.
 
-This result presents an index of XProc elements used in pipelines described in this tutorial. For any XProc element used anywhere, the listing shows the pipelines where it appears. It also shows a list of project folders in the order they are treated by this tutorial, showing for each one the XProc files found there along with whatever XProc elements appear *first* (within the tutorial sequence) within that pipeline.
+Next, take a look at a more complex example, the prototype pipeline [PRODUCE-PROJECTS-ELEMENTLIST.xpl](../../PRODUCE-PROJECTS-ELEMENTLIST.xpl). Like the setup and smoke-test pipelines, this is a standalone pipeline: it acquires inputs, produces results and writes those results to the file system. The output it generates is stored as [element-directory.md](../../sequence/element-directory.md), a Markdown file (find the `p:store` step).
 
-Delete or rename this result file and run the pipeline to confirm it functions properly.
+The result is a reference resource: an index of XProc elements used in pipelines described in this tutorial. For any XProc element used anywhere, the listing shows the pipelines where it appears. It also shows a list of (repository) project folders in an order corresponding to their treatment (if any) in this tutorial, with their XProc files. Along with these are listed whatever XProc elements appear *first* (within the entire sequence up to to point) within that file. Among other uses this is helpful for assessing coverage of lessons.
+
+For example, looking up `p:store` you can see all the pipelines that contain this common step. Or looking at the `oscal-convert` listing you can see the XProc steps introduced in that lesson.
 
-The Markdown file produced may be useful for finding XPoc examples in the repository. First, an ordered list of pipelines indicates which XProc steps are used &ldquo;first&rdquo; (i.e., within the sequence, which parallels the lesson sequence). Following this is a list of all steps with all pipelines containing them. For example, looking up `p:store` you can see all the pipelines that contain this common step.
+Delete or rename this result file and run the pipeline to confirm it functions properly.
 
 Consider also what other kinds of indexing might be useful. When you modify XProc or add new XProc pipelines to the project folders, consider running this pipeline again to update the indexes.
 
-Open the file and inspect it to get a sense of what it does. The XML syntax is verbose, but not really all that frightening. The pipeline is described in more detail in the [102 Lesson unit](unpack_102.md) in this lesson.
+Open the file and inspect it to get a sense of what it does. The XML syntax is verbose, but not really all that frightening. The pipeline is described in more detail in the [102 Lesson unit](walkthrough_102.md) segment.
+
+### PRODUCE-PROJECTS-ELEMENTLIST
 
-### What do we see
+The pipeline [PRODUCE-PROJECTS-ELEMENTLIST.xpl](../../PRODUCE-PROJECTS-ELEMENTLIST.xpl) contains comments that should help explain its operations.
 
-There are two significant differences between this pipeline and the small ones we have looked at so far.
+There are some significant differences between this pipeline and the small ones we have looked at so far.
 
 * Of course, it is longer and more complex, reflecting the complexity of the operations it performs.
-* Unlike the test pipelines, this XProc has no input port, hence no way to provide documents to be considered as input. Instead, it collects data to process by *reading the file system* and loading files directly. This is especially useful here as it includes everything it finds – meaning we can extend or update the index by adding files and running the pipeline again, without altering any pipeline logic.
+* Part of the complexity is due to a two-step process here. First, the file system is surveyed in locations named in an input configuration. Then all those resources (which happen to be XML using the XProc vocabulary) are indexed against the files in which they occur.
+* In particular, the index to &ldquo;first use&rdquo; is not simple. A great deal of the complexity of detailed operations has been off-loaded into XSLT transformation code, which in this pipeline can be seen embedded in the XProc, indeed occupying a significant majority of the XML in the file. (About two thirds of the element count you can usually recognize XSLT by the conventional `xsl:` or `xslt:` element prefix.) This pipeline also has one XSLT called from an external file, toward the end. XProc can do it either way, and each has its advantages.
+* One good thing about seeing the XSLT here is you can get a good sense of what it looks like, whether embedded or kept externally.
 
 ## XML syntax, XPath and XProc
 
@@ -135,16 +152,16 @@ Newcomers to XML may feel they are in the deep water with XML syntax.
 In the context of XProc, this is actually not as hard as it looks:
 
 * All XML files follow the same syntax rules with respect to tags, elements and attributes (names and syntax), namespaces, comments etc.
-* XML vocabularies are typically qualified with namespaces to show, and disambiguate, which XML application or language they belong to. The namespaces are indicated by name prefixes. So in this repository (and conventionally for XProc), any element prefixed `p:` is an XProc element, and another prefix or none indicates an extension or another vocabulary, such as appears in XML being processed.
+* XML vocabularies are typically qualified with namespaces to show, and to disambiguate, which XML application or language they belong to. The namespaces are indicated by name *prefixes*. So in this repository (and conventionally for XProc), any element prefixed `p:` is an XProc element, and another prefix or none indicates an extension or another vocabulary, such as appears in XML being processed.
 * Embedded in the syntax is another syntax, *XPath*. This lightweight but powerful query language is a formal subset of XQuery. XPath is ubiquitous in XProc, XSLT, Schematron, XSpec etc. In XProc, the XPath will ordinarily be given in attributes.
-* Learn more about this in the [102 Lesson unit](unpack_102.md) – or plunge on, and pick up what you need as you go.
+* Learn more about this in the [102 Lesson unit](walkthrough_102.md) – or plunge on, and pick up what you need as you go.
 
 ## Learning more about XProc
 
-This tutorial has a handmade[XProc links page](../../xproc-links.md) with links.
+This tutorial has a handmade [XProc links page](../../xproc-links.md) with links.
 
 Also, see the official [XProc.org dashboard page](https://xproc.org).
 
-Also, check out indexing logic offered in the [xproc-doc                project folder](../../../projects/xproc-doc/readme.md). It has pipelines producing useful indexes to XProc in this repository and in general, including one producing an [index to XProc simple steps](XPROC-STEP-INDEX-HTML.xpl), with code snips.
+Also, check out indexing logic offered in the [xproc-doc                project folder](../../../projects/xproc-doc/readme.md). It has pipelines producing useful indexes to XProc in this repository and in general, including one producing an [index to XProc                simple steps](../../../projects/xproc-doc/XPROC-STEP-INDEX-HTML.xpl) in HTML, with code snips.
 
 There is [a book, Erik Siegel's XProc 3.0                   Programmer's Reference](https://xmlpress.net/publications/xproc-3-0/) (2020) and an [excellent                reference site](https://xprocref.org/index.html) by the same author.
diff --git a/tutorial/sequence/Lesson02/unpack_102.md b/tutorial/sequence/Lesson02/walkthrough_102.md
similarity index 95%
rename from tutorial/sequence/Lesson02/unpack_102.md
rename to tutorial/sequence/Lesson02/walkthrough_102.md
index fe4fa7e4..eb4ec59e 100644
--- a/tutorial/sequence/Lesson02/unpack_102.md
+++ b/tutorial/sequence/Lesson02/walkthrough_102.md
@@ -1,6 +1,6 @@
 
 
-> *Warning:* this Markdown file will be rewritten under continuous deployment (CD): edit the source in [/tutorial/source/unpack/unpack_102_src.html](../../../tutorial/source/unpack/unpack_102_src.html).
+> *Warning:* this Markdown file will be rewritten under continuous deployment (CD): edit the source in [/tutorial/source/walkthrough/walkthrough_102_src.html](../../../tutorial/source/walkthrough/walkthrough_102_src.html).
 > 
 > Save this file elsewhere to create a persistent copy (for example, for purposes of annotation).
 
@@ -16,7 +16,7 @@
 
 ## Prerequisites
 
-You have done [Setup 101](../setup/setup_101.md), [Setup 102](../setup/setup_101.md) and [Unpack 101](unpack_101.md).
+You have done [Setup 101](../acquire/acquire_101.md), [Setup 102](../acquire/acquire_101.md) and [Unpack 101](walkthrough_101.md).
 
 ## Resources
 
@@ -28,7 +28,7 @@ Also, the official [XProc.org dashboard page](https://xproc.org)
 
 Also, check out XProc index materials produced in this repository: [XProc docs](../../../projects/xproc-doc/readme.md)
 
-And the same pipelines you ran in setup: [Setup                101](../setup/setup_101.md).
+And the same pipelines you ran in setup: [Setup                101](../acquire/acquire_101.md).
 
 ## Learning more about XProc
 
@@ -41,7 +41,7 @@ A partial list of ways to learn more about XProc:
 
 ## Details details!
 
-XProc pipelines described in [the previous lesson unit](unpack_101.md) contain a few noteworthy features.
+XProc pipelines described in [the previous lesson unit](walkthrough_101.md) contain a few noteworthy features.
 
  To edit these files, use any XML-capable plain text editor (that is, with care, any editor at all that saves text files as UTF-8).
 
diff --git a/tutorial/sequence/Lesson02/walkthrough_399.md b/tutorial/sequence/Lesson02/walkthrough_399.md
new file mode 100644
index 00000000..f97ea6d7
--- /dev/null
+++ b/tutorial/sequence/Lesson02/walkthrough_399.md
@@ -0,0 +1,165 @@
+
+
+> *Warning:* this Markdown file will be rewritten under continuous deployment (CD): edit the source in [/tutorial/source/walkthrough/walkthrough_399_src.html](../../../tutorial/source/walkthrough/walkthrough_399_src.html).
+> 
+> Save this file elsewhere to create a persistent copy (for example, for purposes of annotation).
+
+# 399: XProc, XML and XDM (the XML Data Model)
+
+More in depth.
+
+## Goals
+
+* Consider XProc in its operational context including available **standards** and applicable **requirements**, both generalized and local
+* Consider the context of XProc by learning or relearning some deep XML history
+* Inform your capability to assess the utility and appropriateness of XProc in particular and XML in general, for a given problem or domain
+
+## Resources
+
+The same pipelines you ran in setup: [Setup             101](../acquire/acquire_101.md).
+
+Also, [XProc.org dashboard page](https://xproc.org)
+
+Also, XProc index materials produced in this repository: [XProc docs](../../../projects/xproc-doc/readme.md)
+
+## Prerequisites
+
+Coverage here provides background information; there are no prerequisites. Prior exercises, or the practical equivalent, are assumed.
+
+## XProc as XML
+
+XProc is defined as an XML vocabulary. A schema for the XProc language, considered as core steps (compound and atomic) plus optional community-defined steps, is referenced from the [XProc Specification](https://spec.xproc.org/3.0/xproc/#ancillary-files). [This RNG schema](https://spec.xproc.org/3.0/xproc/xproc30.rng) is very useful.
+
+It may often be considered gratuitous to validate XProc files against a schema, when the application (for us, Morgana) must in any case take responsibility for conformance issues, as it sees fit. The reference schema becomes useful if we find or suspect bugs in Morgana, but until then it need not have any direct role in any runtime operation.
+
+Nevertheless, since XProc is XML, its schema still serves as a reference and an object for querying – queries whose results tell us about XProc. [A pipeline](../../GRAB-XPROC-RESOURCES.xpl) for acquiring both the RNG schema and its RNC (compact syntax) variant is provided for interest and possible later use.
+
+### Survey of XProc elements
+
+All elements defined by XProc (at time of writing) are listed in this analytical breakout.
+
+*However*, this list is provisional and intended only to offer a wider view. For the most up to date information, refer to specifications. In particular, XProc 3.1 makes this list a moving target. This may be out of date by the time you are able to read it.
+
+ NB also – see Erik Siegel's [XProcRef](https://xprocref.org/index.html) indexing project for more detailed summaries.
+
+| Function | XProc elements / p: namespace |
+| Documentation | `p:documentation` |
+| Top-level | `p:declare-step`, `p:library` |
+| Imports | `p:import`, `p:import-functions` |
+| Prologue | `p:input`, `p:output`, `p:option` |
+| Compound steps | `p:group`, `p:for-each`, `p:viewport`, `p:if`, `p:choose` (with `p:when` and `p:otherwise`), `p:try` (with `p:catch` and `p:finally)`, `p:run` (with `p:run-input`, `p:run-option`) |
+| Atomic steps - core - XML | `p:add-attribute`, `p:add-xml-base`, `p:delete`, `p:filter`, `p:identity`, `p:insert`, `p:label-elements`, `p:make-absolute-uris`, `p:namespace-delete`, `p:namespace-rename`, `p:pack`, `p:rename`, `p:replace`, `p:set-attributes`, `p:uuid`, `p:unwrap`, `p:wrap-sequence`, `p:wrap`, `p:xinclude`, `p:xquery`, `p:xslt` |
+| Atomic steps - core - zipping | `p:archive`, `p:archive-manifest`, `p:unarchive`, `p:uncompress` |
+| Atomic steps - core - JSON | `p:json-join`, `p:json-merge`, `p:set-properties` |
+| Atomic steps - core - plain text | `p:string-replace`, `p:text-count`, `p:text-head`, `p:text-join`, `p:text-replace`, `p:text-sort`, `p:text-tail` |
+| Atomic steps - core - utility | `p:cast-content-type`, `p:compare`, `p:compress`, `p:count`, `p:error`, `p:hash`, `p:http-request`, `p:load`, `p:sink`, `p:split-sequence`, `p:store`, `p:www-form-urldecode`, `p:www-form-urlencode` |
+| Atomic steps - optional - file system | `p:directory-list`, `p:file-copy`, `p:file-delete`, `p:file-info`, `p:file-mkdir`, `p:file-move`, `p:file-create-tempfile`, `p:file-touch` |
+| Atomic steps - optional - validation | `p:validate-with-nvdl`, `p:validate-with-relax-ng`, `p:validate-with-schematron`, `p:validate-with-xml-schema`, `p:validate-with-json-schema` |
+| Other optional steps | `p:os-info`, `p:os-exec`, `p:css-formatter`, `p:xsl-formatter`, `p:markdown-to-html` |
+| Variable declaration | `p:variable` |
+| Connectors | `p:with-input`, `p:with-option`, `p:pipe`, `p:pipeinfo`, `p:document`, `p:inline`, `p:empty` |
+
+## XML and the XDM: context and rationale
+
+The technologies we rely on share a common foundation in XML and XDM (the XML data model), technologies developed under the auspices of the World Wide Web Consortium (W3C). For stability over a long term (years and decades rather than months), we require solutions that are:
+
+* Standard, non-proprietary and freely available without restriction
+* Consistently and repeatedly shown to be capable at scale (size/complexity)
+* Supported by commodity tools, easing problem of proprietary product dependencies
+
+Importantly, we need tools that are freely available to use without restriction, an important qualification for this distribution, which has a prior commitment *not to endorse particular technological solutions to any problem*, however posed or circumscribed. Accordingly, solutions here are not offered as recommendations, but rather as stipulations of (minimum) viable functionality in tools or capabilities, and not only using tools as &ldquo;black boxes&rdquo;, but under control and conformant to external specifications – i.e., standards.
+
+Users should keep in mind the model whereby we imagine the viability of a tools market and ecosystem that enables both large and small software developers – including independent developers, academic researchers, and students – to participate meaningfully, finding an appropriate value or service proposition to support immediate and long-term goals. Translated, this means the tools must be capable enough for industrial use at scale, while they must also &ldquo;scale down&rdquo; to demonstration or classroom use.
+
+In web standards including HTML and Javascript (ECMAScript) we arguably have the beginnings of such an ecosystem, while it is also contested and turbulent. Within the publishing sector more broadly and intersecting with the web, the XML family of standards arguably provides the best demonstration of complete or near-complete capabilities at least with respect to the harder problems of document processing.
+
+* XSLT up to [XSLT 3.0](https://www.w3.org/TR/xslt-30/) (in [Saxon](https://www.saxonica.com/welcome/welcome.xml))
+* [XQuery](https://www.w3.org/TR/xquery-31/) (in Saxon)
+* [Schematron](https://github.com/Schematron) (in [SchXSLT](https://github.com/schxslt/schxslt), an open-source implementation in XSLT of [Schematron](https://schematron.com/) including the [ISO/IEC 19757-3](https://www.iso.org/obp/ui/#iso:std:iso-iec:19757:-3:ed-3:v1:en) specification
+* [XSpec](https://github.com/xspec/xspec), a community-maintained XSLT-based framework for test-driven development, supporting testing XSLT, XQuery and Schematron
+
+Since they are known to be highly conformant to their respective specifications as well as well tested, these tools provide a useful functional baseline for evaluating other tooling that addresses the same functional requirements.
+
+They are also, relatively speaking, *mature* technologies, at least in comparison to similar offerings.
+
+And when XProc works, we also have the functional underpinnings we need for comparing - for example - different XSLT implementations.
+
+Initiated in 1996, XML continues to be generative in 2024.
+
+## Snapshot history: an XML time line
+
+[TODO: complete this, or move it, or both]
+
+| Year | Publication | Capabilities | Processing frameworks | Platforms |
+| --- | --- | --- | --- | --- |
+| 1987 | SGML (ISO-IEC 8879-1) | parsing logic; schema validation; configurable syntax; (implicit) tree of elements and attributes | Proprietary stacks | Mainframes, workstations |
+| 1996 | Unicode 2.0 | standard character sets | … support for Unicode is slow to come | PCs |
+| 1998 | XML 1.0 | standard syntax | Batch processing, shell scripts, `make` | Mainframes, workstations, PCs (x86 generation), *nix, shell, sed/awk, Perl |
+| 1999 | XPath 1.0, XSLT 1.0 | basic tree querying and transformations (&ldquo;down hill&rdquo;); functional support for namespaces | Web browsers? (some, sort of); standalone XSLT processors |  |
+| 2000 |  | XML-configured software builds | Apache Ant | Java |
+|  |  |  |  | Perl, Python |
+|  | XQuery 1.0 |  |  |  |
+|  | XPath 2.0 |  | Server frameworks (Apache Cocoon) |  |
+| 2001 | XML Schema Definition language (XDM) | Standardizes atomic data types (foundations of XSD); namespace-based validation (RNG also offers this, 2001-2002) |  |  |
+| 2003 |  | Pipelining as a build process | Apache Ant | Java |
+| 2003-2004 | W3C Document Object Model (DOM) | API for HTML and XML documents |  |  |
+| 2005 | &ldquo;The XML data model&rdquo; (W3C) | An essay |  |  |
+| 2006 | XProc 1.0 Requirements |  |  | Proof-of-concept demonstrations |
+| 2007 | XSLT 2.0 | Transformations (&ldquo;up hill&rdquo;) including grouping, string processing, pipelining |  |  |
+|  | XDM (XPath/XQuery data model) | Unifying a data model for XPath, XSLT and XQuery |  | Client- and server-side XML processing stacks |
+|  |  |  | XQuery+XSLT in eXist-db or BaseX (XQuery engines) |  |
+|  | XPath 3.0 |  |  |  |
+|  | XPath 3.1 | Higher-order functions, map and array objects |  |  |
+| 2010 | XProc 1.0 |  |  |  |
+| 2017 | XSLT 3.0/3.1 | JSON harmonization, functions as arguments |  |  |
+|  | XProc 3.0 | Easier syntax, plus adding support for JSON and other content types |  |  |
+| 2022 | Unicode 15.0 |  |  |  |
+
+The technologies have been in constant use over this period.
+
+Historically, the requirements of processing frameworks have often been met by software developers' build utilities (for example, GNU `make` or Apache Ant). This is not an accident: in certain respects, a publishing framework can be considered as a &ldquo;documentary build&rdquo;, to be run at intervals corresponding to the publishing cycle with its proof runs.
+
+## XPath
+
+Like other XDM-based technologies, XProc embeds and incorporates XPath, an expression language for XML. XPath 3.0 is a functional language in its own right, although not designed for end-to-end processing of encoded source data into encoded results, but only for certain critical operations that ordinarily need to be performed within such end-to-end processing. Importantly, XPath is defined not in terms of any data notation (such as XML syntax or any other) but rather against an *abstract data object*, namely an [XDM](https://www.w3.org/TR/xpath-datamodel/) instance (XML data model), a putative information object that may be provided to the system by parsing an XML (syntax) instance, or by other means. As the query language for [XDM](https://www.w3.org/TR/xpath-datamodel/) and the basis for XQuery, [XPath](https://www.w3.org/TR/xpath-31/) is the &ldquo;other half&rdquo; of the data model, which any architect of a system using this technology must know. Learning XPath equips you mentally for dealing with the XDM in XQuery, XSLT, XProc or anywhere you find it.
+
+For those not already familiar with XPath, on line resources can be helpful. Keep in mind that [XPath 3.1](https://www.w3.org/TR/xpath-31/) outstrips earlier versions of the language in many important respects (supporting map and function objects with higher-order functions, among other features).
+
+### Documents and data
+
+One of the more important features of XPath and the XDM is that they are designed not only to meet needs for the representation and transmission of structured data. A specialized class of data formats has evolved that represent information in ways that are not &ldquo;unstructured&rdquo;, but that contrast with more common or usual structures of data formats, whether they be tabular data, serialization formats for object models, or some other regular (formalized and codified) arrangement for purposes of machine-readability. One might say &ldquo;common&rdquo; or &ldquo;usual&rdquo; with reservation, since of course documents are not uncommon where they are common. The prevalence of so-called structured data in digital systems may tell us more about the limits of those systems than it does about information in general.
+
+We see a great deal of structured data these days if only because it is so easy to make structured data with machines, and we now have the machines. What remains difficult is to translate what has not been created by a machine, into a form that a machine can &ldquo;recognize&rdquo;, or rather into a form we can recognize in and with the machine, without mishandling it and distorting it. Since machines do not recognize anything (nothing is &ldquo;mishandling&rdquo; to them), what this often reduces to in practice is deciding how to agree on a **representation** for information that any creator and any consumer can recognize and work with, without seeing the information first. In itself this is a formidable challenge.
+
+So documents are called &ldquo;unstructured&rdquo; but they might better be called &ldquo;relatively irregular&rdquo;, meaning not that they have no structure, but that each one is structured in itself, and moreover, likely to be incompatible or not fully compatible with encodings designed to capture other structures.
+
+And to the extent this is the case, any encoding capable of describing documents must have the capability of supporting each document's own distinctive structure and organization, whether that be due to its family (what is called a **document type**) or an expression of its own intrinsic logic. The format must be not only structured, but *structurable*, and its structures must to some extent be capable of self-description – combining data with metadata.
+
+And this is to give no consideration to the fact that these structures can be described at *multiple levels* of generality or specificity with regard to either their supposed semantics, or their configuration in operation.
+
+Documentary data formats especially markup formats are designed to work in this in-between space.
+
+And so we get XPath - a query syntax which permits working with an organized structure of a particular kind (an *XDM document tree*), which in turn is designed for handling the combination of *highly regular* and *quite irregular* data structures that characterize information sets we (loosely) call **documentary**.
+
+A definition for what is a document is out of scope for this tutorial – an interesting topic but not only a technical one.
+
+### XPath illustrative examples
+
+This is not the place to learn XPath, but a selection of XPath expressions can offer a hint of its capabilities.
+
+| XPath | Returns | XPath long (explicit) notation |
+| --- | --- | --- |
+| `/html` | An XML document root (top-level) element named `html` (subject to namespace resolution) | `/child::html` |
+| `//p` | All the elements named `p` in the document | `/descendant-or-self::element()/ child::p` |
+| `//seg[@type='null']` | All the elements named `seg` with an attribute `type` with value `null` | `/descendant-or-self::element()/ child::seg[attribute::type='null']` |
+| `/*` | Any document (rather, any element at the top of a document) - `*` is a wildcard character | `/child::element()` |
+| `/section[exists(.//table)]` | An element inside the top-level element, named `section`, that contains a `table` element anywhere inside it | `/child::section[exists(self::node()/ descendant-or-self::element()/ child::table)]` |
+| `/descendant::p[10]` | The tenth `p` element in the document | `/descendant::p[position() eq 10]` |
+| `//p[10]` | All `p` elements, that are the tenth `p` inside their respective parents | `/descendant-or-self::element()/ child::p[position() eq 10]` |
+| `//section[count(.//p) gt 10]` | All `section` elements that contain more than 10 `p` elements, at any depth | `/child::section[count(self::node()/ descendant-or-self::element()/ child::p) gt 10]` |
+
+Where do you find XPath? Any `select` or `match` expression in XSLT or XProc shows an example. XPath also constitutes the core of XQuery.
+
+## Exercise: Discussion board
+
+Create or contribute to a Github discussion board offering perspective or (especially!) relevant information or experience on any of the larger questions.
diff --git a/tutorial/sequence/Lesson02/walkthrough_401.md b/tutorial/sequence/Lesson02/walkthrough_401.md
new file mode 100644
index 00000000..c5035e47
--- /dev/null
+++ b/tutorial/sequence/Lesson02/walkthrough_401.md
@@ -0,0 +1,90 @@
+
+
+> *Warning:* this Markdown file will be rewritten under continuous deployment (CD): edit the source in [/tutorial/source/walkthrough/walkthrough_401_src.html](../../../tutorial/source/walkthrough/walkthrough_401_src.html).
+> 
+> Save this file elsewhere to create a persistent copy (for example, for purposes of annotation).
+
+# 401 - XSLT Forward and Back
+
+What is this XSLT?
+
+Read this page if you are a beginner, or an expert in XSLT, or if you plan never to use it.
+
+## Goals
+
+* If you don't know XSLT, helps you understand what it is and what it does
+* If you know XSLT, understand something more about how it fits with XProc
+
+## Resources
+
+XSLT links!
+
+### XSLT 1.0 and XPath 1.0
+
+### XSLT 2.0 and XQuery 1.0
+
+### XSLT 3.0, XQuery 3.0, XPath 3.1
+
+## Prerequisites
+
+You have run and inspected pipelines mentioned earlier, most especially [PRODUCE-PROJECTS-ELEMENTLIST.xpl](../../PRODUCE-PROJECTS-ELEMENTLIST.xpl), which contains `p:xslt` steps.
+
+You have inspected XSLT files (standalone transformations or *stylesheets*), to be found more or less anywhere in this repository, especially directories named `src`.
+
+## XSLT: XSL (XML Stylesheet Language) Transformations
+
+XSLT has a long and checkered reputation and a history that may be even more amazing.
+
+Chances are good that if you are not current on the latest version of this technology, you have little idea of what we are talking about, as it may have changed quite a bit (and even despite external appearances) since you last saw it.
+
+Users who last used XSLT 1.0 and even 2.0, in particular, can consider their knowledge out of date until they have taken a look at XSLT 3.0.
+
+Programmers can think of XSLT as a domain-specific language (DSL) or fourth-generation language (4GL) designed for the purpose of manipulating data structures suitable for documents and messages as well as for structured data sets. As such, XSLT is highly generalized and abstract and can be applied to a very broad range of problems. Its main distinguishing feature among similar languages (which tend to be functional languages such as Scala and Scheme) is that it is optimized for use specifically with XML-based data formats, offering well-defined handling of information sets expressed in XML, while the language itself uses XML syntax, affording nice composability, reflection and code generation capabilities. XSLT's processing model is both broadly applicable, and workable in a range of environments including client software or within encapsulated, secure software configurations and deployments.
+
+If your XSLT is strong enough, you don't need XProc, or not much. But as a functional language, XSLT is best used in a functionally pure way that does not interact with the system: no &ldquo;side effects&rdquo;. This is related to its definitions of conformant processing (X inputs produce Y outputs) and the determinism, based in mathematical formalisms, that underlies this idea of conformance. However one cost of mathematical purity is that operations that do interact with stateful externalities – things such as reading and writing files – are not in XSLT's &ldquo;comfort zone&rdquo;. It easily defines what a new structure A' should look like for any given structure A. But how A is first acquired or what we do once we have determined A', is less clear, and left up to the processor to handle, as an interface, starting with an XSLT transformation's nominal *source* and (primary) *result*. Often, this gap has been bridged by extended functionality provided by leading processors. Does your processor read and parse XML files off the file system? Can it be connected to upstream processes in different ways? Can it use HTTP `GET` and `PUT`? The answer may be Yes to any or all of these. Throughout its history, XSLT in later versions was also extended in this direction, with features such as the `collection()` function, `xsl:result-document`, `doc-available()` and other features we don't need if we are using XProc.
+
+Then too, XSLT is commonly run from scripts, in web hosting environments, and indeed from XQuery. Or you might be able to configure your desktop software (Editor or IDE) to run your XSLT, or indeed acquire specialized software just for reading and filtering collections or managing sets of file outputs in XSLT-based workflows.
+
+It is difficult not to think, however, that a gentler approach is also possible to the range of problems related to making XSLT accessible in any environment – one that offers the feature set and flexibility we need, but with less overhead, especially with regard to routine chores like designating sets of inputs and outputs, or sequencing operations. The principle of Least Power may well apply here: it saves our present and our future selves effort if we can arrange and manage to do things less. XProc lets us do less.
+
+XProc lets us use XSLT when we must, but also keeps routine and simple things both simple and consistent, without requiring much overhead. But it adapts itself well to new requirements as they become more complicated. Ultimately, it spares the XSLT developer the problem of having to design, build and test something like XProc.
+
+### Running XSLT without XProc
+
+As a standard and an externally-specified technology, XSLT can in principle be implemented on any platform, but the leading XSLT implementation for some years has been Saxon, produced by Saxonica of Reading, England. Saxon has achieved market share and developer support on a record of strictly-conformant, performant applications, deployed as an open-source software product free for developers to use and integrate. (While doing this, Saxonica also has related product offerings including optimized processor for those who choose to support it.)
+
+Download and run Saxon to apply XSLT to XML and other inputs, without XProc.
+
+## Learning XSLT the safer way
+
+If setting out to learn XSLT, pause to read the following list of things to which you should give early attention, in order:
+
+
+1. Namespaces in XML and XSLT: names, name prefixes, unprefixed names and the `xpath-default-namespace` setting (not available until XSLT 2.0)
+
+1. Templates and modes in XSLT: template matching, `xsl:apply-templates`, built-in templates, and using modes to configure default behaviors when no template matches
+
+1. XPath, especially absolute and relative location paths: start easy and work up
+
+Only one of these topics does not also apply to XProc.
+
+## XProc without XSLT?
+
+XProc does not require XSLT absolutely, even if XSLT is indispensable for some of XProc libraries, including those in this repository.
+
+How could we do without it?
+
+* Using XQuery any time queries get complicated
+* Use XProc where possible, for example steps that support matches on patterns? E.g. `p:insert`, `p:label-elements` and `p:add-attribute`
+* Reliance on iterators and `p:viewport`
+* Much smarter (declarative, data-centric) HTML or other dialect in the application space?
+
+Chances are, there is a limit. One thing XSLT does better than almost any comparable technology is support generalized or granular mappings between vocabularies.
+
+So not only creating, but also consuming HTML, is the place we begin with XSLT. But since it is also very fine for other vocabulary mappings in the middle and back, it becomes indispensable almost as soon as it is available for use.
+
+## XProc, XDM (the XML data model) and the standards stack
+
+Another critical consideration is whether and to what extent XProc and XSLT introduce unwanted dependencies, which make them strategically not a good choice (or not a good choice for everyone) at least in comparison to alternatives. These are standards in every way including nominally - emerging as the work of organizations such as W3C and ISO, while not escaping a reputation as &ldquo;boutique&rdquo; or &ldquo;niche&rdquo; technologies. Yet alternative models – whether to go with the big guys, or rely on forests of Javascript libraries, or support a bespoke Markdown-based stack – have not all fared very well either. Often scorned, XSLT has a reputation for projects migrating away from it as much as towards it. Yet look closely, and when problems arise, XSLT is never the issue by itself. Often the question is, were you even using the right tool? one way is to be in the sweet spot (and there is a sweet spot) of document processing at scale, but this is not definitive. Sometimes the question is, are you actually fitting the capabilities of the processing model to the problem at hand. Too often, that fit happens by accident.
+
+So where has XML-based processing been not only tenable but rewarding over the long term? Interestingly, its success is to be found often in projects that have survived across more than one system over time, that have grown from one system into another, and that have morphed and adapted and grown new limbs. (Pubmed Central comes to mind. But what about Optical Society? PLOS?) In other words, look at them today and you do not see the same system as you would have only five years ago.
diff --git a/tutorial/sequence/Lesson03/oscal-convert_101.md b/tutorial/sequence/Lesson03/oscal-convert_101.md
new file mode 100644
index 00000000..957655f0
--- /dev/null
+++ b/tutorial/sequence/Lesson03/oscal-convert_101.md
@@ -0,0 +1,99 @@
+
+
+> *Warning:* this Markdown file will be rewritten under continuous deployment (CD): edit the source in [/tutorial/source/oscal-convert/oscal-convert_101_src.html](../../../tutorial/source/oscal-convert/oscal-convert_101_src.html).
+> 
+> Save this file elsewhere to create a persistent copy (for example, for purposes of annotation).
+
+# 101: OSCAL from XML to JSON and back
+
+## Goals
+
+Learn how OSCAL data can be converted between JSON and XML formats, using XProc.
+
+Learn something about potential problems and limitations when doing this, and about how to detect, avoid, prevent or mitigate them.
+
+Become familiar with the idea of generic conversions between syntaxes such as XML and JSON (not always possible), versus conversions designed to handle a single class or type of documents, such as OSCAL format conversions.
+
+## Prerequisites
+
+You have succeeded in prior exercises, including tools installation and setup.
+
+## Resources
+
+This unit relies on the [oscal-convert project](../../../projects/oscal-convert/readme.md) in this repository, with its files. Like all projects in the repo, it aims to be reasonably self-contained and self-explanatory. Use your search engine and XProc resources to learn background and terminology.
+
+Also like other projects, there are preliminaries for acquiring resources, along with pipelines to run.
+
+## Step zero: an identity pipeline
+
+To verify syntactic correctness (well-formedness) - does it parse?
+
+To transcode a file from one encoding to another
+
+## Step zero-point-five: XML to JSON and back
+
+XML and JSON are both *data serializations*, a term that designates how each of them is to be considered and treated – irrespective of any questions of information storage – as a *sequence of characters*. This is a very important commonality, which makes it possible to bring them together in a single processing environment such as XProc.
+
+Along with *plain text*, perhaps the most important data serialization or &ldquo;format&rdquo; as we call them, of the three.
+
+A simple XProc pipeline can be used to demonstrate this. While doing so, it shows also while this is not as simple a process as it seems. Merely to convert from format to format is not enough.
+
+## Step one: convert some OSCAL XML into OSCAL JSON
+
+[An acquisition pipeline](../../../projects/oscal-convert/GRAB-RESOURCES.xpl) in the project folder collects some OSCAL onto the local system, where it can be managed, easily inspected, controlled, and edited if necessary.
+
+TBD / this all incoherent so far
+
+### The playing field is the internet
+
+Keep in mind that XProc in theory, and your XProc engine in practice, may read its inputs using whatever protocols it supports, while the `file` and `http` protocols are required for conformance, and work as they do on the Worldwide Web.
+
+Of course, permissions must be in place to read files from system locations, or save files to them.
+
+But when authentication is configured or resources are openly available, using `http` to reach resources or sources can be a very convenient option.
+
+### Consider the options
+
+TBD - TODO - question - how many and of what sort of source data files - so far there is only the cat catalog
+
+* Converting local XML to JSON with a local XSLT
+* Converting local data using a remote XSLT
+* Remote data with a local XSLT, writing locally - you could try [https://github.com/GSA/fedramp-automation/blob/master/dist/content/rev5/baselines/xml/FedRAMP_rev5_LOW-baseline-resolved-profile_catalog.xml](https://github.com/GSA/fedramp-automation/blob/master/dist/content/rev5/baselines/xml/FedRAMP_rev5_LOW-baseline-resolved-profile_catalog.xml)
+
+## Step two: return trip
+
+Two ways: separate pipeline; and single pipeline; also a 'switcher' pipeline?
+
+## What is this XSLT?
+
+If your criticism of XProc so far is that it makes it look easy when it isn't, you have a point.
+
+Conversion from XML to JSON isn't free, assuming it works at all.
+
+In this case, the heavy lifting is done by the XSLT component - the Saxon engine invoked by the `p:xslt` step, applying logic defined in an XSLT stylesheet (aka transformation) stored elsewhere. It happens that a converter for OSCAL data is available in XSLT, so rather than having to confront this considerable problem ourselves, we drop in the solution we have at hand.
+
+In later units we will see how using the XProc steps described, rudimentary data manipulations can be done using XProc by itself, without entailing the use of either XSLT or XQuery (another capability invoked with a different step).
+
+At the same time, while pipelines are based on the idea of passing data through a series of processes, there are many cases where logic is sufficiently complex that it becomes essential to maintain – and test – that logic externally from the XProc. At what point it becomes more efficient to encapsulate logic separately (whether by XSLT, XQuery or other means), depends very much on the case.
+
+The `p:xslt` pipeline step in particular is so important for real-world uses of XProc that it is introduced early, to show such a black-box application.
+
+XProc also makes a fine environment for testing XSLT developed or acquired to handle specific tasks, a topic covered in more depth later.
+
+Indeed XSLT and XQuery being, like XProc itself, declarative languages, it makes sense to factor them out while maintaining easy access and transparency for analysis and auditing purposes.
+
+## What could possibly go wrong?
+
+When coping with errors, syntax errors are relatively easy. But anomalous inputs, especially invalid inputs, can result in lost data. (A common reason data is not valid even when it appears to be is that it has foreign unknown contents, or contents out of place - the kinds of things that might fail to be converted.) The most important concern when engineering a pipeline is to see to it that no data quality problems are introduced inadvertantly. While in comparison to syntax or configuration problems, data quality issues can be subtle, there is also good news: the very same tools we use to process inputs into outputs, can also be used to test and validate data to both applicable standards and local rules.
+
+Generally speaking, OSCAL maintains &ldquo;validation parity&rdquo; between its XML and JSON formats with respect to their schemas. That is to say, the XSD (XML schema) covers essentially the same set of rules for OSCAL XML data as the JSON Schema does for OSCAL JSON data, accounting for differences between the two notations, the data models and how information is mapped into them. A consequence of this is that valid OSCAL data, either XML or JSON, can reliably be converted to valid data in the other notation, while invalid data may not be converted at all, resulting in gaps or empty results.
+
+For this and related reasons on open systems, the working principle in XML is often to formalize a model (typically by writing and deploying a schema) as early as possible - or adopt a model already built - as a way to institute and enforce schema validation as a **prerequisite** and **primary requirement** for working with any data set. Validation against schemas is covered in a subsequent lesson unit (coming soon near you).
+
+### Intercepting errors
+
+One way to manage the problem of ensuring input quality is to validate on the way in, either as a dependent (prerequisite) process, or built into a pipeline. Whatever you want to do with invalid inputs, including ignoring them and producing warnings or runtime exceptions, can be defined in a pipeline much like anything else.
+
+In the [publishing demonstration                   project folder](../../../projects/oscal-publish/publish-oscal-catalog.xpl) is an XProc that valides XML against an OSCAL schema, before formatting it. The same could be done for an XProc that converts the data into JSON - either or both before or after conversion.
+
+Learn more about recognizing and dealing with errors in [Lesson 102](oscal-convert_102.md), or continue on to the next project, oscal-validate, for more on validation of documents and sets of documents.
diff --git a/tutorial/sequence/Lesson03/oscal-convert_102.md b/tutorial/sequence/Lesson03/oscal-convert_102.md
new file mode 100644
index 00000000..2f37367a
--- /dev/null
+++ b/tutorial/sequence/Lesson03/oscal-convert_102.md
@@ -0,0 +1,156 @@
+
+
+> *Warning:* this Markdown file will be rewritten under continuous deployment (CD): edit the source in [/tutorial/source/oscal-convert/oscal-convert_102_src.html](../../../tutorial/source/oscal-convert/oscal-convert_102_src.html).
+> 
+> Save this file elsewhere to create a persistent copy (for example, for purposes of annotation).
+
+# 102: Hands on data conversions
+
+## Goals
+
+Learn how OSCAL data can be converted between JSON and XML formats, using XProc.
+
+Learn something about potential problems and limitations when doing this, and about how to detect, avoid, prevent or mitigate them.
+
+Work with XProc features designed for handling JSON data (XDM **map** objects that can be cast to XML).
+
+## Prerequisites
+
+Run the pipelines described in [the 101                Lesson](https://github.com/usnistgov/oscal-xproc3/discussions/18)
+
+## Resources
+
+Same as the [101 lesson](oscal-convert_101.md).
+
+## Some breaking and making
+
+Every project you examine provides an opportunity to alter pipelines and see how they fail when not encoded correctly – when &ldquo;broken&rdquo;, any way we can think of breaking them. Then build good habits by repairing the damage. Experiment and observation bring learning.
+
+After reading this page and [the project readme](../../../projects/oscal-convert/readme.md), run the pipelines while performing some more disassembly / reassembly. Here are a few ideas (including a few you may have already done):
+
+* Switch out the value of an `@href` on a `p:document` or `p:load` step. See what happens when the file it points to is not actually there.
+* There is a difference between `p:input`, used to configure a pipeline in its prologue, and `p:load`, a step that loads data. Ponder what these differences are. Try changing a pipeline that uses one into a pipeline that uses the other.
+* Similarly, there is a difference between a `p:output` configuration for a pipeline, and a `p:store` step executed by that pipeline. Consider this difference and how we might define a rule for when to prefer one or the other. How is the pipeline used - is it called directly, or intended for use as a step in other pipelines? How is it to be controlled at runtime?
+* Try inserting `p:store` steps into a pipeline to capture intermediate results, that is, the output of any step before they are processed by the next step. Such steps can aid in debugging, among other uses.
+* `@message` attributes on steps provide messages for the runtime traceback. They are optional but this repo follows a rule that any `p:load` or `p:store` should be provided with a message. Why?
+* A `p:identity` step passes its input unchanged to the next step. But can also be provided with a `@message`.
+
+After breaking anything, restore it to working order. Create modified copies of any pipelines for further analysis and discussion.
+
+* Concept: copy and change one of the pipelines provided to acquire a software library or resource of your choice.
+
+## Value templates in attributes and text: { expr }
+
+## Designating an input at runtime by binding input ports
+
+One potential problem with the pipelines we have looked at so far is that their inputs are hard-wired. While this is sometimes helpful, it should also be possible to apply a pipeline to an XML document (or other input) without having to designate the document inside the pipeline itself. The user or calling application should be able to say &ldquo;run this pipeline, but this time with this input&rdquo;.
+
+The input ports for a pipeline, specified using `p:input` within the prologue, provide for this.
+
+For example, the [CONVERT-OSCAL-XML-DATA](../../../projects/oscal-convert/CONVERT-OSCAL-XML-DATA.xpl) pipeline defines an input port:
+
+```
+<p:input port="source" sequence="true">
+    <p:document href="data/catalog-model/xml/cat_catalog.xml"/>
+</p:input>
+```
+
+By default, this pipeline will pick up and process the data it finds at path `data/catalog-model/xml/cat_catalog.xml`, relative to the stylesheet. But any call to this pipeline, whether directly or as a step in another pipeline, can override this.
+
+The Morgana processor defines [a command                syntax for binding inputs to ports](https://www.xml-project.com/manual/ch01.html#R_ch1_s1_2). It looks like this (when used with the script deployed with this repository):
+
+```
+$ ../xp3.sh *PIPELINE.xpl* -input:*portname=path/to/a-document.xml* -input:*portname=path/to/another-document.xml*
+```
+
+Here, two different `-input` arguments are given for the same port. You can have as many as needed if the port, like this one, has `sequence="true"`, meaning any number of documents (from zero to many) can be bound to the port, and the pipeline will accommodate. When more than one port is defined, one (only) can be designated as `primary="true"`, meaning it will be provided implicitly when a port connection is required (by a step) but not given in the pipeline. Notice that the name of the port must also appear, as in `-input:portname`, since pipelines can have ports supporting sequences, but also as many input ports as it needs, named differently, for documents playing different roles in the pipeline. In place of `portname` here, a common name for a port (conventional when it is the pipeline's only or primary input) is `source`.
+
+### Binding to input ports vs p:load steps
+
+XProc offers two ways to acquire data from outside the pipeline: by using `p:load` or by binding inputs to an input port using `p:input/p:document`. These are somewhat different in operation - errors produced by `p:load` cannot be detected until the pipeline is run, whereas failures with `p:input` should be detected when the pipeline itself is loaded and compiled (i.e. during *static analysis*), and processors may be able to apply different kinds of exception handling, fallbacks or support for redirects. (As always you can try, test and determine for yourself.) Apart from this distinction the two approaches have similar effects – whether to use one or the other depends often on how you expect the pipeline to be used and distributed, not on whether it works.
+
+Although one distinction is that p:document appears on input ports, which can be overridden, this does not mean that p:document can't be essentially &ldquo;private&rdquo; to a pipeline or pipeline step. For example, if you wish to acquire more than a single document, without p:load, known in advance (i.e. the file names can be hard-coded), make a step like this:
+
+```
+<p:identity>
+  <p:with-input>
+    <p:document href="..."/>
+    <p:document href="..."/>
+    ...
+  </p:with-input>
+<p:identity>
+```
+
+This binds the documents to the input of an **identity** step (which supports a sequence), without exposing an input port in the main pipeline.
+
+A more dynamic approach is sometimes useful: first, acquire a list of file names, for example:
+
+```
+<p:input port="source">
+   <p:inline>
+      <FILELIST>
+         <FILE>A</FILE>
+         <FILE>B</FILE>
+      </FILELIST>
+   </p:inline>
+</p:input>
+```
+
+Then in our subpipeline we use the compound step `p:for-each` to process each FILE element in the list:
+
+```
+<p:for-each>
+   <p:with-input select="//FILE"/>
+   <p:load href="{ string(.) }"/>
+</p:for-each>   
+```
+
+This has the effect of traversing the document given in line (the file list) and for each of its FILE elements, loading the document named as the FILE element's string value, that is &ldquo;A&rdquo;, &ldquo;B&rdquo; and so on. This is just as if A and B had been bound directly to the port. In either case, what we get is a sequence of XDM *document* objects, one for each of the resources parsed.
+
+One tradeoff is that the override mechanism will be different. We override the first approach by binding the pipeline's `source` port directly to whatever documents we want in place of A and B. We override the second approach by providing a different FILELIST document. Alternatively such a FILELIST can be referenced instead of included … `p:document href="the-filelist.xml`, providing us a resource that we can maintain separately.
+
+This makes the second approach especially appealing if the file list can be derived from some kind of metadata resource or, indeed, `p:directory-list`….
+
+## Identity pipeline testbed
+
+An identity or &ldquo;near-identity&rdquo; or modified-identity pipeline has its uses, including diagnostics. Since inputs and outputs are supposed to look the same, any changes they show between inputs and outputs can be revealing.
+
+They are also useful for testing features, for example features for resource acquisition and disposition. These are fancy ways to describe how you get data into your pipeline and then out again.
+
+Additionally, there are actually useful operations supported by a pipeline that pretends to change nothing. For example, it can transcode a file from one encoding to another – changing nothing in the data, but rewriting it into a different character set.
+
+### 0.01 - what is a &ldquo;document&rdquo;
+
+### 0.1 - loading documents known or determinable in advance
+
+The XProc step `p:load` can be used to load the resource indicated into the pipeline.
+
+Watch out, since `p:load` with `href=''` – loading the resource at the location indicated by the empty string, `""` – will load the XProc file itself. This is conformant with rules for URL resolution.
+
+### 0.2 - binding a document to an input port
+
+### 0.3 - loading documents dynamically on discovery with `p:directory-list`
+
+### 0.4 - saving results to the file system
+
+### 0.5 - exposing results on an output port
+
+## Probing error space - data conversions
+
+Broadly speaking, problems encountered running these conversions fall into two categories, the distinction being simple, namely whether a bad outcome is due to an error in the processor and its logic, or in the data inputs provided. The term &ldquo;error&rdquo; here hides a great deal. So does &ldquo;bad outcome&rdquo;. One type of bad outcome takes the form of failures at runtime - the term &ldquo;failure&rdquo; again leaving questions open. Other bad outcomes are not detectable at runtime. If inputs are bad (inconsistent with stated contracts such as data validation), processes can run *correctly* and deliver incorrect results: correctly representing inputs, in their incorrectness. Again, the term *correct* here is underspecified and underdefined, except in the case.
+
+### Converting broken XML or JSON
+
+### Converting broken OSCAL
+
+### Converting not-OSCAL
+
+## XProc diagnostic how-to
+
+### Emitting runtime messages
+
+### Saving out interim results
+
+`p:store`
+
+## Validate early and often
diff --git a/tutorial/sequence/Lesson03/oscal-convert_399.md b/tutorial/sequence/Lesson03/oscal-convert_399.md
new file mode 100644
index 00000000..0a05b6f8
--- /dev/null
+++ b/tutorial/sequence/Lesson03/oscal-convert_399.md
@@ -0,0 +1,241 @@
+
+
+> *Warning:* this Markdown file will be rewritten under continuous deployment (CD): edit the source in [/tutorial/source/oscal-convert/oscal-convert_399_src.html](../../../tutorial/source/oscal-convert/oscal-convert_399_src.html).
+> 
+> Save this file elsewhere to create a persistent copy (for example, for purposes of annotation).
+
+# 399: XProc in more depth
+
+## Goals
+
+Get more in-depth information about XProc internals.
+
+## Prerequisites
+
+You have succeeded in prior exercises, including tools installation and setup. You have seen enough XProc to be impressed, but possibly also a little intimidated.
+
+## Resources
+
+Again, reference is made to pipelines and processes defined for the [oscal-convert project](../../../projects/oscal-convert/readme.md).
+
+## Overview: the anatomy of an XProc pipeline
+
+Experts in XML can read this section quickly. Newcomers will find some of the concepts here (such as namespaces) also apply across XML- and XDM-based technologies including XSLT and Schematron. XDM is the [XQuery and XPath Data Model](https://www.w3.org/TR/xpath-datamodel/), the foundation of XPath, XQuery and XSLT.
+
+### XProc files
+
+An XProc pipeline takes the form of an XML &ldquo;document entity&rdquo;. Unless you are concerned to write an XML parser (which is not very likely for XProc's natural constituency), this typically means an XML file, that is to say a file encoded in plain text (typically the UTF-8 serialization of Unicode, or alternatively another form of &ldquo;plain text&rdquo; supported by your toolkit), and following the rules of XML syntax. These rules include how elements and attributes and other XML features are encoded in **tags** that
+
+* Follow the rules with respect to naming, whitespace, delimiters and reserved characters
+* Are correctly balanced, with an end tag for every start tag – for a `<start>` there must be a `</start>` (an end to the start).
+* Are cleanly nested with no overlap: end tags always close the most recently opened element, so no element ever extends beyond the boundaries of its &ldquo;ancestor&rdquo; or containing elements
+
+These rules are fairly simple, and they are well supported by tools designed to read and write XML – to respect, follow and enforce the rules on our behalf.
+
+Thus they are also quickly and easily internalized, often in only a few minutes of working with XML.
+
+Over and above being XML, XProc has some rules of its own ...
+
+#### XProc document element
+
+```
+<p:declare-step version="3.0"
+   xmlns:p="http://www.w3.org/ns/xproc"
+   xmlns:ox="http://csrc.nist.gov/ns/oscal-xproc3"
+   type="ox:TEST-XPROC3"
+   name="TEST-XPROC3">
+...
+</p:declare-step>
+```
+
+#### Namespaces
+
+```
+   xmlns:p="http://www.w3.org/ns/xproc"
+   xmlns:ox="http://csrc.nist.gov/ns/oscal-xproc3"
+```
+
+#### @name and @type
+
+On `p:declare-step`, whether at the top or in a step definition within a pipeline, either or both a `@name` and a `@type` are permitted.
+
+```
+   type="ox:TEST-XPROC3"
+   name="TEST-XPROC3">
+```
+
+The name makes it possible to reference the step by name. This is often useful and sometimes more or less essential, for example for providing input to one step from another step's output. (We say &ldquo;more or less essential&rdquo; because the processor will produce names for itself as a fallback, if it needs them, but these are brittle, somewhat opaque – such as `!1.2.3` – and more difficult to use than the names a developer gives.)
+
+Understandably, the name of an XProc must be different from the names given to all the steps in the XProc (which must also be distinct). 
+
+This repository follows a rule that a step name should correspond to its file base name (i.e., without a filename suffix), so `identity_` for `identity_.xproc`, etc. But that is a rule for us, not for XProc in general.
+
+A step may also have an assigned `@type`. Unlike the name, which can be in any namespace or none, the `@type` must be assigned to a namespace.
+
+### Prologue and body
+
+Keep in mind that to build a pipeline is also to design and deploy a step, since any pipeline can be used as a step, and any step may comprise, internally, a pipeline.
+
+Since step definitions are more often &ldquo;out of line&rdquo; (in an external file) than inline (in the XProc itself), 
+
+As described in the [XProc 3.0                   specification](https://spec.xproc.org/3.0/xproc/#declare-pipelines), XProc step declarations can be divided into an initial set of elements for setup and configuration, followed by what the specification calls a *subpipeline*, consisting of a sequence of steps to be executed – any steps available, which could be anything. Think of the subpipeline as the working parts of the pipeline, while the rest is all about how it is set up.
+
+The list of elements that come before the subpipeline is short, which helps: `p:import`, `p:import-functions`, `p:input`, `p:output`, `p:option` or `p:declare-step`. Everything coming after is a step.
+
+Within this set of elements (all preceding, none following the subpipeline) XProc further distinguishes between the **imports** for steps and functions, appearing first (elements `p:import` and `p:import-functions`), to be followed by elements configuring the step: `p:input`, `p:output`, `p:option` – elements together called the [prologue](https://spec.xproc.org/3.0/xproc/#declare-pipelines).
+
+The prologue is used to define ports and options for the pipeline. It can be thought of as the definition of the interface for the step as a whole. Defining ports and options is how you give the users of the step with the affordances or control points they need to use it. If only a single input is needed, a single input port (named `source`) can be assumed (XXX is this so?), so prologues can be empty (and invisible, or not there).
+
+Following the prologue, a step may also have local step definitions (`p:declare-step`). One might think of these as macros: maybe they are never used by another pipeline (XXX test: is this even possible?), but these locally-defined pipelines can be used internally for logic that is used repeatedly, or that warrants separating from the main pipeline for some other reason.
+
+After imports, prologue and (optional) step declarations, the step sequence that follows comprises the [subpipeline](https://spec.xproc.org/3.0/xproc/#dt-subpipeline).
+
+One other complication: among the steps in the subpipeline, `p:variable` (a variable declaration) and `p:documentation` (for out-of-band documentation) are also permitted – these are not properly steps, but can be useful to have with them.
+
+In summary: any XProc pipeline, viewed as a step declaration, can have the following --
+
+* Pipeline name and type assignment (if needed), given as attributes at the top
+* **Imports**: step declarations, step libraries and functions to make available
+* The pipeline **prologue**: any of the elements named `p:input`, `p:output` and `p:option`, defining this pipeline's ports and options
+  * If no ports are named, assume a single `source` primary input port, permitting a single document
+* Optionally (and not common): step declarations for local steps, appearing at `p:declare-step`. Each of these will have its own name, type, prologue and steps
+* For this pipeline, one or more steps, called the [subpipeline](https://spec.xproc.org/3.0/xproc/#dt-subpipeline)
+  * Standard atomic and compound steps in XProc namespace (probably prefixed `p:`)
+  * Imported steps - in their own namespaces (in this repository, prefixed `ox:`)
+  * Variable declarations - `p:variable`
+* Finally, as noted above, `p:documentation` can appear anywhere in a pipeline, but it will be ignored except when appearing inside `p:inline`. What to do with these is a topic to be covered later.
+
+NB: the pipelines run so far have XML comments demarcating the prologue from the steps.
+
+### XProc steps
+
+The *step* is the core conceptual unit of XProc. An XProc processing pipeline is composed of steps. But a pipeline is also considered as a step in itself. As such it can be used in other pipelines, and so on.
+
+In other words, steps in XProc are *compositional*. They are building block assemblies made out of smaller building block assemblies. A step is a way to process data. A pipeline is a way of orchestrating and arranging such processes.
+
+The distinction between pipelines and steps is relative and provisional, but important and useful. The pipeline is the logical and actual definition of how your data is to be processed. Every pipeline is composed of an arrangement, often a series, of operations. These operations – the steps – include &ldquo;primitives&rdquo;, being designed for generality and reusability for the most common operations. But they can also include new steps we have written, as pipelines, and such custom-designed steps can be used in combination with the primitives or core compound steps of the language.
+
+At a higher level, defining new steps with new step declarations, and using them in combination with other steps, is how we manage complexity and change in processing requirements. This strategy maximizes adaptability, while also supporting an &ldquo;incremental maturity model&rdquo;, in which all defined processes can be improved with reuse, building and testing over time. Careful use and deployment of new steps is how we save work, by focusing optimization and making it possible to scale up to address data processing requirement sets that are both large and complex.
+
+Accommodating this design, an XProc *file* considered as an XML instance is either of two things: a *step declaration*, or a collection of such declarations, a *library*. At the top level, recognize an XProc step declaration by the element, `p:declare-step` (in the XProc namespace) and a library by the element `p:library`.
+
+```
+<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="3.0" 
+    name="a-first-step">
+...
+</p:declare-step>
+```
+
+Additionally, step declarations can include their own pipeline (step) declarations, making a hybrid architecture: the pipeline comprises a step, with its own library not imported but in line. This can also be useful.
+
+An example of a step library in this repository is [xspec-execute.xpl](../../../xspec/xspec-execute.xpl), which collects several steps supporting XSpec, one each for supporting the XSpec testing framework for XSLT, XQuery and Schematron respectively.
+
+The advantage of defining a step at the top level, rather than putting all steps into libraries, is that such a step can be invoked without prior knowledge of its type name, which is used by XProc to distinguish it from other steps. The pipeline simply needs to be presented to the processor, which does the rest.
+
+#### XProc as an XML document
+
+Like any language using XML syntax, XProc depends on a conceptual relation between primitive constructs of the language, and XML syntax, a relation that is ordinarily (and usefully) mediated by means of an (actual or putative) XML *data model* including elements, attributes, comment nodes, text nodes and so forth. XSLT is such a language, for example: it has its top-level *declarations*, its *template rules* and its *instructions*, all of which are represented using elements in the (standard and most commonly used) XML syntax. Thus, part of learning XSLT is learning that `xsl:key` is syntax for a &ldquo;key declaration&rdquo; while `xsl:template` is a &ldquo;template rule&rdquo;.
+
+In the same way, elements in XProc's XML vocabulary correspond to structures in XProc - structures which developers and users rely on, as they define both the internals and the &ldquo;control interface&rdquo; for the language as a semantic construct - something that &ldquo;does something&rdquo;. In XProc, those structures include things like **documents**, **content-types** (think of &ldquo;formats&rdquo; such as XML and JSON), **ports** and **steps**. Some XProc elements represent steps, others do not. (In the same way as an XSLT key declaration is not a template rule.) Learning this difference among others is how you learn XProc.
+
+Fortunately, the vocabulary of the language is not very large. Core XProc 3.0 has only 95 elements defined in its namespace (or 99, if you are strictly counting all element types defined, not just the names those elements are given). XProc 3.1 adds a few more. This includes elements for all the core and community-defined steps (recognizable by the prefix `p:`). Additional to these 95 might be other steps you acquire or define. As with any language, there are parts you will hardly ever use, while other parts are used routinely.
+
+#### XProc embedded documentation
+
+An example of this is the XProc `p:documentation` element. This element is designed to carry documentation to a consuming application. Rather than mandate some kind of behavior for `p:documentation` – something difficult or impossible to do for the general case, or to test –- the XProc rule is &ldquo;anything marked as documentation is for some other consumer&rdquo;, i.e. a documentation engine, not the XProc processor. In other words, a conformant processor [must ignore anything it sees](https://spec.xproc.org/3.0/xproc/#documentation) inside `p:documentation`.
+
+There is a small loophole, namely that the effect of `p:inline` for capturing XML overrides this provision, so if you put `p:documentation` inside `p:inline`, it &ldquo;becomes visible&rdquo; as inline content, not as XProc to be operated on (or not).
+
+As always it is up to the developer how thoroughly and in what form to include inline documentation. And short of managing a corpus of code documentation along with the code, placing explanatory remarks and code snippets into comments is a widely followed practice, and recommended for its combination of ease and usefulness.
+
+### Atomic and compound steps
+
+Given an understanding of the organization of an XProc pipeline, the focus shifts to the steps themselves, which follow a common pattern. Briefly put, an atomic step is any step you use by simply invoking it with inputs and options: its logic is self-contained, and the operation it carries out is (at least conceptually) &ldquo;single&rdquo; and unified. A compound step, in contrast, combines one or more other steps in a *subpipeline* and manages these together through a single interface.
+
+XProc keeps things workable by providing only a few compound steps supporting the identified range of needs. This does not prove to be a practical limitation, since all steps including atomic steps can have multiple inputs and outputs, distinguished by type and role. (For example, a validation step might output both a copy of the input, potentially annotated, along with a validation report.) Atomic steps are not necessarily simple, and may include compound steps in their own subpipelines, either externally or even within the same step declaration. Accordingly, compound steps are not necessarily more complex than atomic steps: they are useful because they handle common contingencies such as splicing (with `p:viewport`), splitting (with `p:for-each`, perform an operation in parallel over a set of inputs, not a single document), conditionals (`p:if`, `p:choose`) and exception handling (`p:try` with `p:catch` and `p:finally`).
+
+Here are all the compound steps. All others are atomic steps.
+
+* [p:group](https://spec.xproc.org/3.0/xproc/#p.group) - group a subpipeline (step sequence) into a single logical step
+* [p:if](https://spec.xproc.org/3.0/xproc/#p.if) - execute a subpipeline conditionally
+* [p:choose](https://spec.xproc.org/3.0/xproc/#p.choose) - execute a subpipeline conditionally (`switch/case` operator)
+* [p:for-each](https://spec.xproc.org/3.0/xproc/#p.for-each) - produce subpipeline results for each member of a sequence of inputs (documents or nodes)
+* [p:viewport](https://spec.xproc.org/3.0/xproc/#p.viewport) - reproduce outputs, except splicing subpipeline results in place of matched nodes (elements) in the input
+* [p:try](https://spec.xproc.org/3.0/xproc/#p.try) - execute a subpipeline, and deliver its results, or if it fails, run a fallback subpipeline given in a `p:catch`
+
+Additionally to these elements, XProc subpipelines may contain variable declarations (`p:variable`) and documentation (`p:documentation`), as noted.
+
+### Namespaces and extension steps
+
+We recognize steps because we either recognize them by name - for standard steps in the `p:` (XProc) namespace such as `p:filter` and `p:add-attribute` - or sometimes by process of elimination – because they cannot be anything else. This is because extension steps, whether written or acquired, can be named anything. Fortunately, extension steps in XProc take the form of elements in an *extension namespace*. Generally speaking, that is, any element not prefixed with `p:` is treated as out of scope for XProc and to be ignored, while subject to evaluation as an extension.
+
+But this is an important category, since such extensions may include XProc steps whose functioning is core to the pipeline as a whole.
+<details><summary>Question: Where are extension steps used in the XProcs run so far?</summary>
+
+One answer: The [XSpec smoke test](./../../../smoketest/TEST-XSPEC.xpl) calls an extension step named `ox:execute-xspec`, defined in an imported pipeline. In this document, the prefix `ox` is bound to a utility namespace, `http://csrc.nist.gov/ns/oscal-xproc3`.
+
+In an XProc pipeline (library or step declaration) one may also see additional namespaces, including
+
+* The namespaces needed for XSLT, XSD, or other supported technology
+* One or more namespaces deployed by the XProc author to support either steps or internal operations (for example, XSLT functions)
+* The namespace `http://www.w3.org/ns/xproc-step`, usually associated with the name prefix `c:`. This namespace is designated by XProc in order to help standardize the interfaces (inputs and outputs) supported by standard steps.
+* The namespace `http://www.w3.org/ns/xproc-error`, for XProc's error reportingThese declarations (often but not always at the top of the document) are critically important for XPath and hence for the correct operation of your pipelines. See [the specification](https://spec.xproc.org/3.0/xproc/#namespaces) for more information.</details>
+
+### Schema for XProc 3.0
+
+See coverage of [XProc, XML and XDM (the XML                   Data Model)](../unpack/unpack_399.md) in the prior lesson unit for a link to the schema for XProc.
+
+## Some breaking and making
+
+Every project you examine provides an opportunity to alter pipelines and see how they fail when not encoded correctly – when &ldquo;broken&rdquo;, any way we can think of breaking them. Then build good habits by repairing the damage. Experiment and observation bring learning.
+
+After reading this page, perform some more disassembly / reassembly. Here are a few ideas:
+
+* Switch out the value of an `@href` on a `p:document` or `p:load` step. See what happens when the file it points to is not actually there.
+* There is a difference between `p:input`, used to configure a pipeline in its prologue, and `p:load`, a step that loads data. Ponder what these differences are. Try changing a pipeline that uses one into a pipeline that uses the other.
+* Similarly, there is a difference between a `p:output` configuration for a pipeline, and a `p:store` step executed by that pipeline. Consider this difference and how we might define a rule for when to prefer one or the other. How is the pipeline used - is it called directly, or intended for use as a step in other pipelines? How is it to be controlled at runtime?
+* Try inserting `p:store` steps into a pipeline to capture intermediate results, that is, the output of any step before they are processed by the next step. Such steps can aid in debugging, among other uses.
+* `@message` attributes on steps provide messages for the runtime traceback. They are optional but this repo follows a rule that any `p:load` or `p:store` should be provided with a message. Why?
+* A `p:identity` step passes its input unchanged to the next step. But can also be provided with a `@message`.
+
+After breaking anything, restore it to working order. Create modified copies of any pipelines for further analysis and discussion.
+
+* Concept: copy and change one of the pipelines provided to acquire a software library or resource of your choice.
+
+## What could possibly go wrong?
+
+When coping with errors, syntax errors are relatively easy. But anomalous inputs, especially invalid inputs, can result in lost data. (A common reason data is not valid even when it appears to be is that it has foreign unknown contents, or contents out of place - the kinds of things that might fail to be converted.) The most important concern when engineering a pipeline is to see to it that no data quality problems are introduced inadvertantly. While in comparison to syntax or configuration problems, data quality issues can be subtle, there is also good news: the very same tools we use to process inputs into outputs, can also be used to test and validate data to both applicable standards and local rules.
+
+Generally speaking, OSCAL maintains &ldquo;validation parity&rdquo; between its XML and JSON formats with respect to their schemas. That is to say, the XSD (XML schema) covers essentially the same set of rules for OSCAL XML data as the JSON Schema does for OSCAL JSON data, accounting for differences between the two notations, the data models and how information is mapped into them. A consequence of this is that valid OSCAL data, either XML or JSON, can reliably be converted to valid data in the other notation, while invalid data may not be converted at all, resulting in gaps or empty results.
+
+For this and related reasons on open systems, the working principle in XML is often to formalize a model (typically by writing and deploying a schema) as early as possible - or adopt a model already built - as a way to institute and enforce schema validation as a **prerequisite** and **primary requirement** for working with any data set. Validation against schemas is covered in a subsequent lesson unit (coming soon near you).
+
+### Intercepting errors
+
+One way to manage the problem of ensuring input quality is to validate on the way in, either as a dependent (prerequisite) process, or built into a pipeline. Whatever you want to do with invalid inputs, including ignoring them and producing warnings or runtime exceptions, can be defined in a pipeline much like anything else.
+
+In the [publishing demonstration                   project folder](../../../projects/oscal-publish/publish-oscal-catalog.xpl) is an XProc that valides XML against an OSCAL schema, before formatting it. The same could be done for an XProc that converts the data into JSON - either or both before or after conversion.
+
+Learn more about recognizing and dealing with errors in [Lesson 102](oscal-convert_102.md), or continue on to the next project, oscal-validate, for more on validation of documents and sets of documents.
+
+## for 599: XProc for JSON
+
+map objects; steps for working with them; interim p:store as debug method; output ports to see results (final and intermediate) or bind them
+
+## for 599: YAML TODO
+
+map objects; steps for working with them
+
+## for 599: XProc port bindings
+
+This is actually a .bat or .sh exercise - write a script that invokes XProc with a binding to a runtime argument
+
+Thus, a script `convert-oscal-catalog-xml.sh mycatalog.xml` could produce `mycatalog.json` from `mycatalog.xml` etc.
+
+Such a script could live in the project directory - do we want an Issue for this work item? 
+
+## for 599: URIs and URI schemes
+
+As described in [the XProc                specification](https://spec.xproc.org/master/head/xproc/#err.inline.D0012), it is up to implementations to define supported URI schemes and data retrieval mechanics, including XML catalogs to support resource caching and indirection, etc.
+
+## for 599: round tripping as process test
diff --git a/tutorial/sequence/Lesson03/oscal-convert_401.md b/tutorial/sequence/Lesson03/oscal-convert_401.md
new file mode 100644
index 00000000..6638fadb
--- /dev/null
+++ b/tutorial/sequence/Lesson03/oscal-convert_401.md
@@ -0,0 +1,51 @@
+
+
+> *Warning:* this Markdown file will be rewritten under continuous deployment (CD): edit the source in [/tutorial/source/oscal-convert/oscal-convert_401_src.html](../../../tutorial/source/oscal-convert/oscal-convert_401_src.html).
+> 
+> Save this file elsewhere to create a persistent copy (for example, for purposes of annotation).
+
+# 401: XProc, XML, JSON and content types
+
+## Goals
+
+Understand a little more about JSON and other data formats in an XML processing environment
+
+## Resources
+
+See links given in the remarks below. This is a topic you can also learn by through trial and error.
+
+## File formats and XProc content type
+
+Media types or what XProc calls *content types* is a concept XProc inherits from Internet standards such as RFC 2045 (1996) and subsequent specifications for file and attachment types on the Internet. Naturally, since a file's nominal format is scoped to its extent (while we have nominally multi-part formats such as `multipart/x-zip`, each media type descriptor is assigned to a file, giving us a single media type per file), this becomes the most useful and transparent way to manage file format distinctions. Names may *mostly* indicate file types, as we conventionally suffix both XML and JSON (`xml` and `json` respectively) if only to keep ourselves sane. But when the system reports a file as `application/xml` we should be inclined to believe it, unless we have better information to the contrary.
+
+Because an XProc processor comes ready to recognize a range of content types, this becomes an indispensable point of control for managing our information across the variety of formats in which we find it. XML is a meta-language, and describes a syntax while not prescribing any semantics beyond the structural semantics implied in element and attribute naming and containment – this proves to be a very useful in the XProc context, since it means that semantics can be abstracted out – the further the better – into externalized transformations and processes (often, XSLTs) that become black boxes and resources to manage, rather than more code in the code base. But the world deals in much more than XML, and XProc makes the same layering and separation of concerns possible with JSON and other standardized or codified serialization formats.
+
+## Content type 'application/json'
+
+XProc follows the lead of XPath in offering two distinct but complementary ways of handling JSON.
+
+### JSON as XPath `map` object
+
+With XPath 3.1 the language now supports arrays and maps as first-class objects. These are an interesting addition to XPath, among other reasons because JSON object types now all have natural equivalents within XDM. Strings, numeric types, Boolean values, and now arrays and maps can be represented and processed natively in XPath. These objects are supported with operations appropriate to them - such that, for example, `$map('field')` or more succinctly `$map?field` will return the value of the `field` field on the map object. Since map keys do not duplicate, they essentially correspond exactly with JSON objects.
+
+XPath maps are [described in full in the XPath                   specification](https://www.w3.org/TR/xpath-31/#id-maps). Acquire a map object (or array object, if appropriate) by interpreting a string using the XPath function [parse-json()](https://www.w3.org/TR/xpath-functions-31/#func-parse-json), or alternatively reading a JSON file using the [json-doc()](https://www.w3.org/TR/xpath-functions-31/#func-json-doc). The pipeline [oscal-convert/src/read-json-map.xpl](../../../projects/oscal-convert/src/read-json-map.xpl) provides an experimental surface for working this functionality.
+
+Much more natural than using an XPath function to acquire a map object, XProc will simply read a JSON file for you, using the same `p:document` or `p:load` as used everywhere else. The processor is able to do the right thing in this case as well, namely read the file input and cast the data into an XDM map structure.
+
+A pipeline with a simple binding to a JSON file, using `p:load` or `p:document`, is enough to demonstrate this.
+
+### Your JSON, as XML
+
+Map objects have the advantage of efficiency but some disadvantages for transparency. They are great for querying, but not necessarily as easy as node trees to see, write in and out (as XML), transform and debug. Because the JSON object structure reduces into a few rudiments, an XML representation of any JSON input is straightforward to produce, as long as names in XML are suitably generic as to type (like `number` and `string`, for example), and correspond to types known in JSON. A vocabulary for doing so is also well defined, quite concise and even reasonably efficient (for processing if not storage). [ This                   vocabulary](https://www.w3.org/TR/xpath-functions-31/#json-to-xml-mapping) is defined in XPath 3.0.
+
+This XML is easy to see: all it requires is the XProc `p:cast-content-type` step with `content-type="application/xml"`, applied to your map object (JSON) input.
+
+If your system already has such XML, you can cast it back to JSON (map or array) using the same step, with `content-type="application/json"`.
+
+## Other content types
+
+Important content types besides XML and JSON include `plain/text` for plain text and two types for HTML: `text/html` (for less rigorous flavors of HTML) and `application/xhtml+xml`. 
+
+These are most important on the input side, because they provide XProc with information it needs to parse the data reliably. They are also useful to specify on outputs. Making them explicit on either input or output ports is a good practice for both documentation and error detection. The XProc Specification gives some information about [how                content type settings can be abbreviated](https://spec.xproc.org/master/head/xproc/#specified-content-types) in some circumstances.
+
+In XProc it is useful to distinguish between content types and serializations – inasmuch as it is only the latter being, for example, that constitute something like strings of text. Content types, in contrast, are more like species of data object, albeit within or accommodated to XDM, as for example HTML content types must be. On the serialization side: XSLT or XQuery users familiar with the output methods `text`, `xml` and `html` should be able to make these work; and serialization settings when XProc writes out its content types to files are indeed guided by [applicable standards](https://www.w3.org/TR/xslt-xquery-serialization-31/)
diff --git a/tutorial/sequence/Lesson04/practicum_219.md b/tutorial/sequence/Lesson04/practicum_219.md
new file mode 100644
index 00000000..19846e59
--- /dev/null
+++ b/tutorial/sequence/Lesson04/practicum_219.md
@@ -0,0 +1,40 @@
+
+
+> *Warning:* this Markdown file will be rewritten under continuous deployment (CD): edit the source in [/tutorial/source/practicum/practicum_219_src.html](../../../tutorial/source/practicum/practicum_219_src.html).
+> 
+> Save this file elsewhere to create a persistent copy (for example, for purposes of annotation).
+
+# Practicum: Learn by Teaching
+
+## Goals
+
+Help your team and allies.
+
+Produce a useful spin-off from a task or problem you need to master anyway.
+
+Learn not only by doing but by writing it down for yourself and others
+
+## Prerequisites
+
+Those with no prior experience in XSLT or declarative markup might think about that before venturing into these waters. This is an awesome exercise but you can't really fake it.
+
+Of course there is no rule that says you have to share your results. As always you are welcome to explore with no prior commitments, and if writing a lesson plan for no one is useful to you, go for it.
+
+## Resources
+
+* Everything in the course you have seen so far
+* Everything else you have seen relating to XProc
+* Your own problems
+* Your own examples
+
+## Improve or enhance a lesson or lesson unit
+
+Astute readers will have observed that a markup-based deployment invites editing. But the authoring or data acquisition model of this tutorial is not Markdown-based - Markdown is paradoxically not used for its intended purpose but as one of several **publication** formats for this data set, which is currently written in an XML-based HTML5 tag set defined for the project. By writing, querying and indexing in XHTML we can use XProc from the start. Extensibility and flexibility in publication is one of the strengths - to publish a new or rearranged tutorial sequence can be done with a few lines and commands. A drag and drop interface supporting XProc makes this even easier, while it is already installed and running under CI/CD, meaning both editorial and code quality checks can be done with every commit.
+
+Improving a page is as simple as editing the copy found in XXX and XXX
+
+Making and deploying a new pages is a little harder: XXX
+
+## Create a new lesson unit ('area')
+
+## Produce a new project and document it with a tutorial
diff --git a/tutorial/sequence/lesson-sequence.md b/tutorial/sequence/lesson-sequence.md
index ab1a6fe0..2a5ab4a3 100644
--- a/tutorial/sequence/lesson-sequence.md
+++ b/tutorial/sequence/lesson-sequence.md
@@ -1,14 +1,26 @@
 
 
 
-### Lesson unit 01
+### Lesson set 01 - acquire
 
-* [101: Project setup and installation](Lesson01/setup_101.md)
-* [102: Examining the setup](Lesson01/setup_102.md)
-* [599: Meeting XProc](Lesson01/setup_599.md)
+* [101: Project setup and installation](Lesson01/acquire_101.md) (OBSERVER)
+* [102: Examining the setup](Lesson01/acquire_102.md) (MAKER)
+* [599: Meeting XProc](Lesson01/acquire_599.md) (LEARNER)
 
-### Lesson unit 02
+### Lesson set 02 - walkthrough
 
-* [101: Unpacking XProc 3.0](Lesson02/unpack_101.md)
-* [102: XProc fundamentals](Lesson02/unpack_102.md)
-* [599: More context](Lesson02/unpack_599.md)
+* [101: Unpacking XProc 3.0](Lesson02/walkthrough_101.md) (OBSERVER)
+* [102: XProc fundamentals](Lesson02/walkthrough_102.md) (MAKER)
+* [399: XProc, XML and XDM  (the XML Data Model)](Lesson02/walkthrough_399.md) (LEARNER)
+* [401 - XSLT Forward and Back](Lesson02/walkthrough_401.md) (LEARNER)
+
+### Lesson set 03 - oscal-convert
+
+* [101: OSCAL from XML to JSON and back](Lesson03/oscal-convert_101.md) (OBSERVER)
+* [102: Hands on data conversions](Lesson03/oscal-convert_102.md) (MAKER)
+* [399: XProc in more depth](Lesson03/oscal-convert_399.md) (LEARNER)
+* [401: XProc, XML, JSON and content types](Lesson03/oscal-convert_401.md) (LEARNER)
+
+### Lesson set 04 - practicum
+
+* [Practicum: Learn by Teaching](Lesson04/practicum_219.md) (MAKER)
diff --git a/tutorial/source/setup/setup_101_src.html b/tutorial/source/acquire/acquire_101_src.html
similarity index 100%
rename from tutorial/source/setup/setup_101_src.html
rename to tutorial/source/acquire/acquire_101_src.html
diff --git a/tutorial/source/setup/setup_102_src.html b/tutorial/source/acquire/acquire_102_src.html
similarity index 100%
rename from tutorial/source/setup/setup_102_src.html
rename to tutorial/source/acquire/acquire_102_src.html
diff --git a/tutorial/source/setup/setup_599_src.html b/tutorial/source/acquire/acquire_599_src.html
similarity index 100%
rename from tutorial/source/setup/setup_599_src.html
rename to tutorial/source/acquire/acquire_599_src.html
diff --git a/tutorial/source/oscal-convert/oscal-convert_399_src.html b/tutorial/source/oscal-convert/oscal-convert_399_src.html
new file mode 100644
index 00000000..0bdde998
--- /dev/null
+++ b/tutorial/source/oscal-convert/oscal-convert_399_src.html
@@ -0,0 +1,397 @@
+<!DOCTYPE html>
+<html xmlns="http://www.w3.org/1999/xhtml">
+   <head>
+      <title>101: OSCAL from XML to JSON and back</title>
+      <meta charset="utf-8" />
+   </head>
+   <body data-track="learner">
+      <h1>399: XProc in more depth</h1>
+      <section>
+         <h2>Goals</h2>
+         <p>Get more in-depth information about XProc internals.</p>
+      </section>
+      <section>
+         <h2>Prerequisites</h2>
+         <p>You have succeeded in prior exercises, including tools installation and setup. You have seen enough XProc to
+            be impressed, but possibly also a little intimidated.</p>
+      </section>
+      <section>
+         <h2>Resources</h2>
+         <p>Again, reference is made to pipelines and processes defined for the <a
+               href="../../../projects/oscal-convert/readme.md">oscal-convert project</a>.</p>
+      </section>
+      <section>
+         <h2>Overview: the anatomy of an XProc pipeline</h2>
+         <p>Experts in XML can read this section quickly. Newcomers will find some of the concepts here (such as
+            namespaces) also apply across XML- and XDM-based technologies including XSLT and Schematron. XDM is the <a
+               href="https://www.w3.org/TR/xpath-datamodel/">XQuery and XPath Data Model</a>, the foundation of XPath,
+            XQuery and XSLT.</p>
+         <section>
+            <h3>XProc files</h3>
+            <p>An XProc pipeline takes the form of an XML <q>document entity</q>. Unless you are concerned to write an
+               XML parser (which is not very likely for XProc's natural constituency), this typically means an XML file,
+               that is to say a file encoded in plain text (typically the UTF-8 serialization of Unicode, or
+               alternatively another form of <q>plain text</q> supported by your toolkit), and following the rules of
+               XML syntax. These rules include how elements and attributes and other XML features are encoded in
+                  <b>tags</b> that</p>
+            <ul>
+               <li>Follow the rules with respect to naming, whitespace, delimiters and reserved characters</li>
+               <li>Are correctly balanced, with an end tag for every start tag – for a <code>&lt;start></code> there
+                  must be a <code>&lt;/start></code> (an end to the start).</li>
+               <li>Are cleanly nested with no overlap: end tags always close the most recently opened element, so no
+                  element ever extends beyond the boundaries of its <q>ancestor</q> or containing elements</li>
+            </ul>
+            <p>These rules are fairly simple, and they are well supported by tools designed to read and write XML – to
+               respect, follow and enforce the rules on our behalf.</p>
+            <p>Thus they are also quickly and easily internalized, often in only a few minutes of working with XML.</p>
+            <p>Over and above being XML, XProc has some rules of its own ...</p>
+            <section>
+               <h4>XProc document element</h4>
+               <pre>&lt;p:declare-step version="3.0"
+   xmlns:p="http://www.w3.org/ns/xproc"
+   xmlns:ox="http://csrc.nist.gov/ns/oscal-xproc3"
+   type="ox:TEST-XPROC3"
+   name="TEST-XPROC3">
+...
+&lt;/p:declare-step></pre>
+            </section>
+            <section>
+               <h4>Namespaces</h4>
+               <pre>   xmlns:p="http://www.w3.org/ns/xproc"
+   xmlns:ox="http://csrc.nist.gov/ns/oscal-xproc3"</pre>
+            </section>
+            <section>
+               <h4>@name and @type</h4>
+               <p>On <code>p:declare-step</code>, whether at the top or in a step definition within a pipeline, either
+                  or both a <code>@name</code> and a <code>@type</code> are permitted.</p>
+               <pre>   type="ox:TEST-XPROC3"
+   name="TEST-XPROC3"></pre>
+               <p>The name makes it possible to reference the step by name. This is often useful and sometimes more or
+                  less essential, for example for providing input to one step from another step's output. (We say
+                     <q>more or less essential</q> because the processor will produce names for itself as a fallback, if
+                  it needs them, but these are brittle, somewhat opaque – such as <code>!1.2.3</code> – and more
+                  difficult to use than the names a developer gives.)</p>
+               <p>Understandably, the name of an XProc must be different from the names given to all the steps in the
+                  XProc (which must also be distinct). </p>
+               <p>This repository follows a rule that a step name should correspond to its file base name (i.e., without
+                  a filename suffix), so <code>identity_</code> for <code>identity_.xproc</code>, etc. But that is a
+                  rule for us, not for XProc in general.</p>
+               <p>A step may also have an assigned <code>@type</code>. Unlike the name, which can be in any namespace or
+                  none, the <code>@type</code> must be assigned to a namespace.</p>
+            </section>
+         </section>
+         <section>
+            <h3>Prologue and body</h3>
+            <p>Keep in mind that to build a pipeline is also to design and deploy a step, since any pipeline can be used
+               as a step, and any step may comprise, internally, a pipeline.</p>
+            <p>Since step definitions are more often <q>out of line</q> (in an external file) than inline (in the XProc
+               itself), </p>
+            <p>As described in the <a href="https://spec.xproc.org/3.0/xproc/#declare-pipelines">XProc 3.0
+                  specification</a>, XProc step declarations can be divided into an initial set of elements for setup
+               and configuration, followed by what the specification calls a <i>subpipeline</i>, consisting of a
+               sequence of steps to be executed – any steps available, which could be anything. Think of the subpipeline
+               as the working parts of the pipeline, while the rest is all about how it is set up.</p>
+            <p>The list of elements that come before the subpipeline is short, which helps: <code>p:import</code>,
+                  <code>p:import-functions</code>, <code>p:input</code>, <code>p:output</code>, <code>p:option</code> or
+                  <code>p:declare-step</code>. Everything coming after is a step.</p>
+            <p>Within this set of elements (all preceding, none following the subpipeline) XProc further distinguishes
+               between the <b>imports</b> for steps and functions, appearing first (elements <code>p:import</code> and
+                  <code>p:import-functions</code>), to be followed by elements configuring the step:
+                  <code>p:input</code>, <code>p:output</code>, <code>p:option</code> – elements together called the <a
+                  href="https://spec.xproc.org/3.0/xproc/#declare-pipelines">prologue</a>.</p>
+            <p>The prologue is used to define ports and options for the pipeline. It can be thought of as the definition
+               of the interface for the step as a whole. Defining ports and options is how you give the users of the
+               step with the affordances or control points they need to use it. If only a single input is needed, a
+               single input port (named <code>source</code>) can be assumed (XXX is this so?), so prologues can be empty
+               (and invisible, or not there).</p>
+            <p>Following the prologue, a step may also have local step definitions (<code>p:declare-step</code>). One
+               might think of these as macros: maybe they are never used by another pipeline (XXX test: is this even
+               possible?), but these locally-defined pipelines can be used internally for logic that is used repeatedly,
+               or that warrants separating from the main pipeline for some other reason.</p>
+            <p>After imports, prologue and (optional) step declarations, the step sequence that follows comprises the <a
+                  href="https://spec.xproc.org/3.0/xproc/#dt-subpipeline">subpipeline</a>.</p>
+            <p>One other complication: among the steps in the subpipeline, <code>p:variable</code> (a variable
+               declaration) and <code>p:documentation</code> (for out-of-band documentation) are also permitted – these
+               are not properly steps, but can be useful to have with them.</p>
+            <p>In summary: any XProc pipeline, viewed as a step declaration, can have the following --</p>
+            <ul>
+               <li>Pipeline name and type assignment (if needed), given as attributes at the top</li>
+               <li><b>Imports</b>: step declarations, step libraries and functions to make available</li>
+               <li>The pipeline <b>prologue</b>: any of the elements named <code>p:input</code>, <code>p:output</code>
+                  and <code>p:option</code>, defining this pipeline's ports and options<ul>
+                     <li>If no ports are named, assume a single <code>source</code> primary input port, permitting a
+                        single document</li>
+                  </ul></li>
+               <li>Optionally (and not common): step declarations for local steps, appearing at
+                     <code>p:declare-step</code>. Each of these will have its own name, type, prologue and steps</li>
+               <li>For this pipeline, one or more steps, called the <a
+                     href="https://spec.xproc.org/3.0/xproc/#dt-subpipeline">subpipeline</a><ul>
+                     <li>Standard atomic and compound steps in XProc namespace (probably prefixed <code>p:</code>)</li>
+                     <li>Imported steps - in their own namespaces (in this repository, prefixed <code>ox:</code>)</li>
+                     <li>Variable declarations - <code>p:variable</code></li>
+                  </ul></li>
+               <li>Finally, as noted above, <code>p:documentation</code> can appear anywhere in a pipeline, but it will
+                  be ignored except when appearing inside <code>p:inline</code>. What to do with these is a topic to be
+                  covered later.</li>
+            </ul>
+            <p>NB: the pipelines run so far have XML comments demarcating the prologue from the steps.</p>
+         </section>
+         <section>
+            <h3>XProc steps</h3>
+            <p>The <i>step</i> is the core conceptual unit of XProc. An XProc processing pipeline is composed of steps.
+               But a pipeline is also considered as a step in itself. As such it can be used in other pipelines, and so
+               on.</p>
+            <p>In other words, steps in XProc are <i>compositional</i>. They are building block assemblies made out of
+               smaller building block assemblies. A step is a way to process data. A pipeline is a way of orchestrating
+               and arranging such processes.</p>
+            <p>The distinction between pipelines and steps is relative and provisional, but important and useful. The
+               pipeline is the logical and actual definition of how your data is to be processed. Every pipeline is
+               composed of an arrangement, often a series, of operations. These operations – the steps – include
+                  <q>primitives</q>, being designed for generality and reusability for the most common operations. But
+               they can also include new steps we have written, as pipelines, and such custom-designed steps can be used
+               in combination with the primitives or core compound steps of the language.</p>
+            <p>At a higher level, defining new steps with new step declarations, and using them in combination with
+               other steps, is how we manage complexity and change in processing requirements. This strategy maximizes
+               adaptability, while also supporting an <q>incremental maturity model</q>, in which all defined processes
+               can be improved with reuse, building and testing over time. Careful use and deployment of new steps is
+               how we save work, by focusing optimization and making it possible to scale up to address data processing
+               requirement sets that are both large and complex.</p>
+            <p>Accommodating this design, an XProc <i>file</i> considered as an XML instance is either of two things: a
+                  <i>step declaration</i>, or a collection of such declarations, a <i>library</i>. At the top level,
+               recognize an XProc step declaration by the element, <code>p:declare-step</code> (in the XProc namespace)
+               and a library by the element <code>p:library</code>.</p>
+            <pre>&lt;p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="3.0" 
+    name="a-first-step">
+...
+&lt;/p:declare-step></pre>
+            <p>Additionally, step declarations can include their own pipeline (step) declarations, making a hybrid
+               architecture: the pipeline comprises a step, with its own library not imported but in line. This can also
+               be useful.</p>
+            <p>An example of a step library in this repository is <a href="../../../xspec/xspec-execute.xpl"
+                  >xspec-execute.xpl</a>, which collects several steps supporting XSpec, one each for supporting the
+               XSpec testing framework for XSLT, XQuery and Schematron respectively.</p>
+            <p>The advantage of defining a step at the top level, rather than putting all steps into libraries, is that
+               such a step can be invoked without prior knowledge of its type name, which is used by XProc to
+               distinguish it from other steps. The pipeline simply needs to be presented to the processor, which does
+               the rest.</p>
+            <section>
+               <h4>XProc as an XML document</h4>
+               <p>Like any language using XML syntax, XProc depends on a conceptual relation between primitive
+                  constructs of the language, and XML syntax, a relation that is ordinarily (and usefully) mediated by
+                  means of an (actual or putative) XML <i>data model</i> including elements, attributes, comment nodes,
+                  text nodes and so forth. XSLT is such a language, for example: it has its top-level
+                     <i>declarations</i>, its <i>template rules</i> and its <i>instructions</i>, all of which are
+                  represented using elements in the (standard and most commonly used) XML syntax. Thus, part of learning
+                  XSLT is learning that <code>xsl:key</code> is syntax for a <q>key declaration</q> while
+                     <code>xsl:template</code> is a <q>template rule</q>.</p>
+               <p>In the same way, elements in XProc's XML vocabulary correspond to structures in XProc - structures
+                  which developers and users rely on, as they define both the internals and the <q>control interface</q>
+                  for the language as a semantic construct - something that <q>does something</q>. In XProc, those
+                  structures include things like <b>documents</b>, <b>content-types</b> (think of <q>formats</q> such as
+                  XML and JSON), <b>ports</b> and <b>steps</b>. Some XProc elements represent steps, others do not. (In
+                  the same way as an XSLT key declaration is not a template rule.) Learning this difference among others
+                  is how you learn XProc.</p>
+               <p>Fortunately, the vocabulary of the language is not very large. Core XProc 3.0 has only 95 elements
+                  defined in its namespace (or 99, if you are strictly counting all element types defined, not just the
+                  names those elements are given). XProc 3.1 adds a few more. This includes elements for all the core
+                  and community-defined steps (recognizable by the prefix <code>p:</code>). Additional to these 95 might
+                  be other steps you acquire or define. As with any language, there are parts you will hardly ever use,
+                  while other parts are used routinely.</p>
+            </section>
+            <section>
+               <h4>XProc embedded documentation</h4>
+               <p>An example of this is the XProc <code>p:documentation</code> element. This element is designed to
+                  carry documentation to a consuming application. Rather than mandate some kind of behavior for
+                     <code>p:documentation</code> – something difficult or impossible to do for the general case, or to
+                  test –- the XProc rule is <q>anything marked as documentation is for some other consumer</q>, i.e. a
+                  documentation engine, not the XProc processor. In other words, a conformant processor <a
+                     href="https://spec.xproc.org/3.0/xproc/#documentation"><i>must ignore</i> anything it sees</a>
+                  inside <code>p:documentation</code>.</p>
+               <p>There is a small loophole, namely that the effect of <code>p:inline</code> for capturing XML overrides
+                  this provision, so if you put <code>p:documentation</code> inside <code>p:inline</code>, it <q>becomes
+                     visible</q> as inline content, not as XProc to be operated on (or not).</p>
+               <p>As always it is up to the developer how thoroughly and in what form to include inline documentation.
+                  And short of managing a corpus of code documentation along with the code, placing explanatory remarks
+                  and code snippets into comments is a widely followed practice, and recommended for its combination of
+                  ease and usefulness.</p>
+            </section>
+         </section>
+         <section>
+            <h3>Atomic and compound steps</h3>
+            <p>Given an understanding of the organization of an XProc pipeline, the focus shifts to the steps
+               themselves, which follow a common pattern. Briefly put, an atomic step is any step you use by simply
+               invoking it with inputs and options: its logic is self-contained, and the operation it carries out is (at
+               least conceptually) <q>single</q> and unified. A compound step, in contrast, combines one or more other
+               steps in a <em>subpipeline</em> and manages these together through a single interface.</p>
+            <p>XProc keeps things workable by providing only a few compound steps supporting the identified range of
+               needs. This does not prove to be a practical limitation, since all steps including atomic steps can have
+               multiple inputs and outputs, distinguished by type and role. (For example, a validation step might output
+               both a copy of the input, potentially annotated, along with a validation report.) Atomic steps are not
+               necessarily simple, and may include compound steps in their own subpipelines, either externally or even
+               within the same step declaration. Accordingly, compound steps are not necessarily more complex than
+               atomic steps: they are useful because they handle common contingencies such as splicing (with
+                  <code>p:viewport</code>), splitting (with <code>p:for-each</code>, perform an operation in parallel
+               over a set of inputs, not a single document), conditionals (<code>p:if</code>, <code>p:choose</code>) and
+               exception handling (<code>p:try</code> with <code>p:catch</code> and <code>p:finally</code>).</p>
+            <p>Here are all the compound steps. All others are atomic steps.</p>
+            <ul>
+               <li><a href="https://spec.xproc.org/3.0/xproc/#p.group"
+                     style="color: rgb(3, 69, 117); text-decoration: none; border-bottom: 1px solid rgb(112, 112, 112); padding: 0px 1px; margin: 0px -1px; font-family: sans-serif; font-size: medium; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: -120px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal;"
+                     ><code class="tag-element language-construct" style="font-family: Consolas, Monaco, &#34;Andale Mono&#34;, monospace; font-size: 16px; break-inside: avoid; hyphens: none; text-transform: none; text-align: left; white-space: pre; color: black; text-shadow: white 0px 1px; direction: ltr; word-spacing: normal; word-break: normal; tab-size: 4; padding: 0.1em; border-radius: 0.3em;">p:group</code></a>
+                  - group a subpipeline (step sequence) into a single logical step</li>
+               <li><a href="https://spec.xproc.org/3.0/xproc/#p.if"
+                     style="color: rgb(3, 69, 117); text-decoration: none; border-bottom: 1px solid rgb(112, 112, 112); padding: 0px 1px; margin: 0px -1px; font-family: sans-serif; font-size: medium; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: -120px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal;"
+                     ><code class="tag-element language-construct" style="font-family: Consolas, Monaco, &#34;Andale Mono&#34;, monospace; font-size: 16px; break-inside: avoid; hyphens: none; text-transform: none; text-align: left; white-space: pre; color: black; text-shadow: white 0px 1px; direction: ltr; word-spacing: normal; word-break: normal; tab-size: 4; padding: 0.1em; border-radius: 0.3em;">p:if</code></a>
+                  - execute a subpipeline conditionally</li>
+               <li><a href="https://spec.xproc.org/3.0/xproc/#p.choose"
+                     style="color: rgb(3, 69, 117); text-decoration: none; border-bottom: 1px solid rgb(112, 112, 112); padding: 0px 1px; margin: 0px -1px; font-family: sans-serif; font-size: medium; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: -120px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal;"
+                     ><code class="tag-element language-construct" style="font-family: Consolas, Monaco, &#34;Andale Mono&#34;, monospace; font-size: 16px; break-inside: avoid; hyphens: none; text-transform: none; text-align: left; white-space: pre; color: black; text-shadow: white 0px 1px; direction: ltr; word-spacing: normal; word-break: normal; tab-size: 4; padding: 0.1em; border-radius: 0.3em;">p:choose</code></a>
+                  - execute a subpipeline conditionally (<code>switch/case</code> operator)</li>
+               <li><a href="https://spec.xproc.org/3.0/xproc/#p.for-each"
+                     style="color: rgb(3, 69, 117); text-decoration: none; border-bottom: 1px solid rgb(112, 112, 112); padding: 0px 1px; margin: 0px -1px; font-family: sans-serif; font-size: medium; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: -120px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal;"
+                     ><code class="tag-element language-construct" style="font-family: Consolas, Monaco, &#34;Andale Mono&#34;, monospace; font-size: 16px; break-inside: avoid; hyphens: none; text-transform: none; text-align: left; white-space: pre; color: black; text-shadow: white 0px 1px; direction: ltr; word-spacing: normal; word-break: normal; tab-size: 4; padding: 0.1em; border-radius: 0.3em;">p:for-each</code></a>
+                  - produce subpipeline results for each member of a sequence of inputs (documents or nodes)</li>
+               <li><a href="https://spec.xproc.org/3.0/xproc/#p.viewport"
+                     style="color: rgb(3, 69, 117); text-decoration: none; border-bottom: 1px solid rgb(112, 112, 112); padding: 0px 1px; margin: 0px -1px; font-family: sans-serif; font-size: medium; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: -120px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal;"
+                     ><code class="tag-element language-construct" style="font-family: Consolas, Monaco, &#34;Andale Mono&#34;, monospace; font-size: 16px; break-inside: avoid; hyphens: none; text-transform: none; text-align: left; white-space: pre; color: black; text-shadow: white 0px 1px; direction: ltr; word-spacing: normal; word-break: normal; tab-size: 4; padding: 0.1em; border-radius: 0.3em;">p:viewport</code></a>
+                  - reproduce outputs, except splicing subpipeline results in place of matched nodes (elements) in the
+                  input</li>
+               <li><a href="https://spec.xproc.org/3.0/xproc/#p.try"
+                     style="color: rgb(3, 69, 117); text-decoration: none; border-bottom: 1px solid rgb(112, 112, 112); padding: 0px 1px; margin: 0px -1px; font-family: sans-serif; font-size: medium; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: -120px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal;"
+                     ><code class="tag-element language-construct" style="font-family: Consolas, Monaco, &#34;Andale Mono&#34;, monospace; font-size: 16px; break-inside: avoid; hyphens: none; text-transform: none; text-align: left; white-space: pre; color: black; text-shadow: white 0px 1px; direction: ltr; word-spacing: normal; word-break: normal; tab-size: 4; padding: 0.1em; border-radius: 0.3em;">p:try</code></a>
+                  - execute a subpipeline, and deliver its results, or if it fails, run a fallback subpipeline given in
+                  a <code>p:catch</code></li>
+            </ul>
+            <p>Additionally to these elements, XProc subpipelines may contain variable declarations
+                  (<code>p:variable</code>) and documentation (<code>p:documentation</code>), as noted.</p>
+         </section>
+         <section>
+            <h3>Namespaces and extension steps</h3>
+            <p>We recognize steps because we either recognize them by name - for standard steps in the <code>p:</code>
+               (XProc) namespace such as <code>p:filter</code> and <code>p:add-attribute</code> - or sometimes by
+               process of elimination – because they cannot be anything else. This is because extension steps, whether
+               written or acquired, can be named anything. Fortunately, extension steps in XProc take the form of
+               elements in an <em>extension namespace</em>. Generally speaking, that is, any element not prefixed with
+                  <code>p:</code> is treated as out of scope for XProc and to be ignored, while subject to evaluation as
+               an extension.</p>
+            <p>But this is an important category, since such extensions may include XProc steps whose functioning is
+               core to the pipeline as a whole.</p>
+            <details><summary>Question: Where are extension steps used in the XProcs run so far?</summary><p>One answer:
+                  The <a href="./../../../smoketest/TEST-XSPEC.xpl">XSpec smoke test</a> calls an extension step named
+                     <code>ox:execute-xspec</code>, defined in an imported pipeline. In this document, the prefix
+                     <code>ox</code> is bound to a utility namespace,
+                  <code>http://csrc.nist.gov/ns/oscal-xproc3</code>.</p><p>In an XProc pipeline (library or step
+                  declaration) one may also see additional namespaces, including</p><ul>
+                  <li>The namespaces needed for XSLT, XSD, or other supported technology</li>
+                  <li>One or more namespaces deployed by the XProc author to support either steps or internal operations
+                     (for example, XSLT functions)</li>
+                  <li>The namespace <code>http://www.w3.org/ns/xproc-step</code>, usually associated with the name
+                     prefix <code>c:</code>. This namespace is designated by XProc in order to help standardize the
+                     interfaces (inputs and outputs) supported by standard steps.</li>
+                  <li>The namespace <code>http://www.w3.org/ns/xproc-error</code>, for XProc's error reporting</li>
+               </ul>These declarations (often but not always at the top of the document) are critically important for
+               XPath and hence for the correct operation of your pipelines. See <a
+                  href="https://spec.xproc.org/3.0/xproc/#namespaces">the specification</a> for more
+               information.</details>
+         </section>
+         <section>
+            <h3>Schema for XProc 3.0</h3>
+            <p>See coverage of <a href="../unpack/unpack_399_src.html" class="LessonUnit">XProc, XML and XDM (the XML
+                  Data Model)</a> in the prior lesson unit for a link to the schema for XProc.</p>
+         </section>
+      </section>
+      <section>
+         <h2>Some breaking and making</h2>
+         <p>Every project you examine provides an opportunity to alter pipelines and see how they fail when not encoded
+            correctly – when <q>broken</q>, any way we can think of breaking them. Then build good habits by repairing
+            the damage. Experiment and observation bring learning.</p>
+         <p>After reading this page, perform some more disassembly / reassembly. Here are a few ideas:</p>
+         <ul>
+            <li>Switch out the value of an <code>@href</code> on a <code>p:document</code> or <code>p:load</code> step.
+               See what happens when the file it points to is not actually there.</li>
+            <li>There is a difference between <code>p:input</code>, used to configure a pipeline in its prologue, and
+                  <code>p:load</code>, a step that loads data. Ponder what these differences are. Try changing a
+               pipeline that uses one into a pipeline that uses the other.</li>
+            <li>Similarly, there is a difference between a <code>p:output</code> configuration for a pipeline, and a
+                  <code>p:store</code> step executed by that pipeline. Consider this difference and how we might define
+               a rule for when to prefer one or the other. How is the pipeline used - is it called directly, or intended
+               for use as a step in other pipelines? How is it to be controlled at runtime?</li>
+            <li>Try inserting <code>p:store</code> steps into a pipeline to capture intermediate results, that is, the
+               output of any step before they are processed by the next step. Such steps can aid in debugging, among
+               other uses.</li>
+            <li><code>@message</code> attributes on steps provide messages for the runtime traceback. They are optional
+               but this repo follows a rule that any <code>p:load</code> or <code>p:store</code> should be provided with
+               a message. Why?</li>
+            <li>A <code>p:identity</code> step passes its input unchanged to the next step. But can also be provided
+               with a <code>@message</code>.</li>
+         </ul>
+         <p>After breaking anything, restore it to working order. Create modified copies of any pipelines for further
+            analysis and discussion.</p>
+         <ul>
+            <li>Concept: copy and change one of the pipelines provided to acquire a software library or resource of your
+               choice.</li>
+         </ul>
+      </section>
+      <section>
+         <h2>What could possibly go wrong?</h2>
+         <p>When coping with errors, syntax errors are relatively easy. But anomalous inputs, especially invalid inputs,
+            can result in lost data. (A common reason data is not valid even when it appears to be is that it has
+            foreign unknown contents, or contents out of place - the kinds of things that might fail to be converted.)
+            The most important concern when engineering a pipeline is to see to it that no data quality problems are
+            introduced inadvertantly. While in comparison to syntax or configuration problems, data quality issues can
+            be subtle, there is also good news: the very same tools we use to process inputs into outputs, can also be
+            used to test and validate data to both applicable standards and local rules.</p>
+         <p>Generally speaking, OSCAL maintains <q>validation parity</q> between its XML and JSON formats with respect
+            to their schemas. That is to say, the XSD (XML schema) covers essentially the same set of rules for OSCAL
+            XML data as the JSON Schema does for OSCAL JSON data, accounting for differences between the two notations,
+            the data models and how information is mapped into them. A consequence of this is that valid OSCAL data,
+            either XML or JSON, can reliably be converted to valid data in the other notation, while invalid data may
+            not be converted at all, resulting in gaps or empty results.</p>
+         <p>For this and related reasons on open systems, the working principle in XML is often to formalize a model
+            (typically by writing and deploying a schema) as early as possible - or adopt a model already built - as a
+            way to institute and enforce schema validation as a <b>prerequisite</b> and <b>primary requirement</b> for
+            working with any data set. Validation against schemas is covered in a subsequent lesson unit (coming soon
+            near you).</p>
+         <section>
+            <h3>Intercepting errors</h3>
+            <p>One way to manage the problem of ensuring input quality is to validate on the way in, either as a
+               dependent (prerequisite) process, or built into a pipeline. Whatever you want to do with invalid inputs,
+               including ignoring them and producing warnings or runtime exceptions, can be defined in a pipeline much
+               like anything else.</p>
+            <p>In the <a href="../../../projects/oscal-publish/publish-oscal-catalog.xpl">publishing demonstration
+                  project folder</a> is an XProc that valides XML against an OSCAL schema, before formatting it. The
+               same could be done for an XProc that converts the data into JSON - either or both before or after
+               conversion.</p>
+            <p>Learn more about recognizing and dealing with errors in <a href="oscal-convert_102_src.html"
+                  class="LessonUnit">Lesson 102</a>, or continue on to the next project, oscal-validate, for more on
+               validation of documents and sets of documents.</p>
+         </section>
+      </section>
+      <section>
+         <h2>for 599: XProc for JSON</h2>
+         <p>map objects; steps for working with them; interim p:store as debug method; output ports to see results
+            (final and intermediate) or bind them</p>
+      </section>
+      <section>
+         <h2>for 599: YAML TODO</h2>
+         <p>map objects; steps for working with them</p>
+      </section>
+      <section>
+         <h2>for 599: XProc port bindings</h2>
+         <p>This is actually a .bat or .sh exercise - write a script that invokes XProc with a binding to a runtime
+            argument</p>
+         <p>Thus, a script <code>convert-oscal-catalog-xml.sh mycatalog.xml</code> could produce
+               <code>mycatalog.json</code> from <code>mycatalog.xml</code> etc.</p>
+         <p>Such a script could live in the project directory - do we want an Issue for this work item? </p>
+      </section>
+      <section>
+         <h2>for 599: URIs and URI schemes</h2>
+         <p>As described in <a href="https://spec.xproc.org/master/head/xproc/#err.inline.D0012">the XProc
+               specification</a>, it is up to implementations to define supported URI schemes and data retrieval
+            mechanics, including XML catalogs to support resource caching and indirection, etc.</p>
+      </section>
+      <section>
+         <h2>for 599: round tripping as process test</h2>
+      </section>
+   </body>
+</html>
\ No newline at end of file
diff --git a/tutorial/source/oscal-convert/oscal-convert_401_src.html b/tutorial/source/oscal-convert/oscal-convert_401_src.html
new file mode 100644
index 00000000..86fd6af4
--- /dev/null
+++ b/tutorial/source/oscal-convert/oscal-convert_401_src.html
@@ -0,0 +1,98 @@
+<!DOCTYPE html>
+<html xmlns="http://www.w3.org/1999/xhtml">
+   <head>
+      <title>401: XProc, XML, JSON and content types</title>
+      <meta charset="utf-8" />
+   </head>
+   <body data-track="learner">
+      <h1>401: XProc, XML, JSON and content types</h1>
+      <section>
+         <h2>Goals</h2>
+         <p>Understand a little more about JSON and other data formats in an XML processing environment</p>
+      </section>
+      <section>
+         <h2>Resources</h2>
+         <p>See links given in the remarks below. This is a topic you can also learn by through trial and error.</p>
+      </section>
+      <section>
+         <h2>File formats and XProc content type</h2>
+         <p>Media types or what XProc calls <em>content types</em> is a concept XProc inherits from Internet standards
+            such as RFC 2045 (1996) and subsequent specifications for file and attachment types on the Internet.
+            Naturally, since a file's nominal format is scoped to its extent (while we have nominally multi-part formats
+            such as <code>multipart/x-zip</code>, each media type descriptor is assigned to a file, giving us a single
+            media type per file), this becomes the most useful and transparent way to manage file format distinctions.
+            Names may <i>mostly</i> indicate file types, as we conventionally suffix both XML and JSON (<code>xml</code>
+            and <code>json</code> respectively) if only to keep ourselves sane. But when the system reports a file as
+               <code>application/xml</code> we should be inclined to believe it, unless we have better information to
+            the contrary.</p>
+         <p>Because an XProc processor comes ready to recognize a range of content types, this becomes an indispensable
+            point of control for managing our information across the variety of formats in which we find it. XML is a
+            meta-language, and describes a syntax while not prescribing any semantics beyond the structural semantics
+            implied in element and attribute naming and containment – this proves to be a very useful in the XProc
+            context, since it means that semantics can be abstracted out – the further the better – into externalized
+            transformations and processes (often, XSLTs) that become black boxes and resources to manage, rather than
+            more code in the code base. But the world deals in much more than XML, and XProc makes the same layering and
+            separation of concerns possible with JSON and other standardized or codified serialization formats.</p>
+      </section>
+      <section>
+         <h2>Content type 'application/json'</h2>
+         <p>XProc follows the lead of XPath in offering two distinct but complementary ways of handling JSON.</p>
+         <section>
+            <h3>JSON as XPath <code>map</code> object</h3>
+            <p>With XPath 3.1 the language now supports arrays and maps as first-class objects. These are an interesting
+               addition to XPath, among other reasons because JSON object types now all have natural equivalents within
+               XDM. Strings, numeric types, Boolean values, and now arrays and maps can be represented and processed
+               natively in XPath. These objects are supported with operations appropriate to them - such that, for
+               example, <code>$map('field')</code> or more succinctly <code>$map?field</code> will return the value of
+               the <code>field</code> field on the map object. Since map keys do not duplicate, they essentially
+               correspond exactly with JSON objects.</p>
+            <p>XPath maps are <a href="https://www.w3.org/TR/xpath-31/#id-maps">described in full in the XPath
+                  specification</a>. Acquire a map object (or array object, if appropriate) by interpreting a string
+               using the XPath function <a href="https://www.w3.org/TR/xpath-functions-31/#func-parse-json"
+                     ><code>parse-json()</code></a>, or alternatively reading a JSON file using the <a
+                  href="https://www.w3.org/TR/xpath-functions-31/#func-json-doc"><code>json-doc()</code></a>. The
+               pipeline <a href="../../../projects/oscal-convert/src/read-json-map.xpl"
+                  >oscal-convert/src/read-json-map.xpl</a> provides an experimental surface for working this
+               functionality.</p>
+            <p>Much more natural than using an XPath function to acquire a map object, XProc will simply read a JSON
+               file for you, using the same <code>p:document</code> or <code>p:load</code> as used everywhere else. The
+               processor is able to do the right thing in this case as well, namely read the file input and cast the
+               data into an XDM map structure.</p>
+            <p>A pipeline with a simple binding to a JSON file, using <code>p:load</code> or <code>p:document</code>, is
+               enough to demonstrate this.</p>
+         </section>
+         <section>
+            <h3>Your JSON, as XML</h3>
+            <p>Map objects have the advantage of efficiency but some disadvantages for transparency. They are great for
+               querying, but not necessarily as easy as node trees to see, write in and out (as XML), transform and
+               debug. Because the JSON object structure reduces into a few rudiments, an XML representation of any JSON
+               input is straightforward to produce, as long as names in XML are suitably generic as to type (like
+                  <code>number</code> and <code>string</code>, for example), and correspond to types known in JSON. A
+               vocabulary for doing so is also well defined, quite concise and even reasonably efficient (for processing
+               if not storage). <a href="https://www.w3.org/TR/xpath-functions-31/#json-to-xml-mapping"> This
+                  vocabulary</a> is defined in XPath 3.0.</p>
+            <p>This XML is easy to see: all it requires is the XProc <code>p:cast-content-type</code> step with
+                  <code>content-type="application/xml"</code>, applied to your map object (JSON) input.</p>
+            <p>If your system already has such XML, you can cast it back to JSON (map or array) using the same step,
+               with <code>content-type="application/json"</code>.</p>
+         </section>
+      </section>
+      <section>
+         <h2>Other content types</h2>
+         <p>Important content types besides XML and JSON include <code>plain/text</code> for plain text and two types
+            for HTML: <code>text/html</code> (for less rigorous flavors of HTML) and <code>application/xhtml+xml</code>. </p>
+         <p>These are most important on the input side, because they provide XProc with information it needs to parse
+            the data reliably. They are also useful to specify on outputs. Making them explicit on either input or
+            output ports is a good practice for both documentation and error detection. The XProc Specification gives
+            some information about <a href="https://spec.xproc.org/master/head/xproc/#specified-content-types">how
+               content type settings can be abbreviated</a> in some circumstances.</p>
+         <p>In XProc it is useful to distinguish between content types and serializations – inasmuch as it is only the
+            latter being, for example, that constitute something like strings of text. Content types, in contrast, are
+            more like species of data object, albeit within or accommodated to XDM, as for example HTML content types
+            must be. On the serialization side: XSLT or XQuery users familiar with the output methods <code>text</code>,
+               <code>xml</code> and <code>html</code> should be able to make these work; and serialization settings when
+            XProc writes out its content types to files are indeed guided by <a
+               href="https://www.w3.org/TR/xslt-xquery-serialization-31/">applicable standards</a></p>
+      </section>
+   </body>
+</html>
\ No newline at end of file
diff --git a/tutorial/source/practicum/practicum_219_src.html b/tutorial/source/practicum/practicum_219_src.html
new file mode 100644
index 00000000..775ae7cf
--- /dev/null
+++ b/tutorial/source/practicum/practicum_219_src.html
@@ -0,0 +1,51 @@
+<!DOCTYPE html>
+<html xmlns="http://www.w3.org/1999/xhtml">
+   <head>
+      <title>Practicum: Learn by Teaching</title>
+      <meta charset="utf-8"/>
+   </head>
+   <body data-track="maker">
+      <h1>Practicum: Learn by Teaching</h1>
+      <section>
+         <h2>Goals</h2>
+         <p>Help your team and allies.</p>
+         <p>Produce a useful spin-off from a task or problem you need to master anyway.</p>
+         <p>Learn not only by doing but by writing it down for yourself and others</p>
+      </section>
+      <section>
+         <h2>Prerequisites</h2>
+         <p>Those with no prior experience in XSLT or declarative markup might think about that before venturing into
+            these waters. This is an awesome exercise but you can't really fake it.</p>
+         <p>Of course there is no rule that says you have to share your results. As always you are welcome to explore
+            with no prior commitments, and if writing a lesson plan for no one is useful to you, go for it.</p>
+      </section>
+      <section>
+         <h2>Resources</h2>
+         <ul>
+            <li>Everything in the course you have seen so far</li>
+            <li>Everything else you have seen relating to XProc</li>
+            <li>Your own problems</li>
+            <li>Your own examples</li>
+         </ul>
+      </section>
+      <section>
+         <h2>Improve or enhance a lesson or lesson unit</h2>
+         <p>Astute readers will have observed that a markup-based deployment invites editing. But the authoring or data
+            acquisition model of this tutorial is not Markdown-based - Markdown is paradoxically not used for its
+            intended purpose but as one of several <b>publication</b> formats for this data set, which is currently
+            written in an XML-based HTML5 tag set defined for the project. By writing, querying and indexing in XHTML we
+            can use XProc from the start. Extensibility and flexibility in publication is one of the strengths - to
+            publish a new or rearranged tutorial sequence can be done with a few lines and commands. A drag and drop
+            interface supporting XProc makes this even easier, while it is already installed and running under CI/CD,
+            meaning both editorial and code quality checks can be done with every commit.</p>
+         <p>Improving a page is as simple as editing the copy found in XXX and XXX</p>
+         <p>Making and deploying a new pages is a little harder: XXX</p>
+      </section>
+      <section>
+         <h2>Create a new lesson unit ('area')</h2>
+      </section>
+      <section>
+         <h2>Produce a new project and document it with a tutorial</h2>
+      </section>
+   </body>
+</html>
\ No newline at end of file
diff --git a/tutorial/source/unpack/unpack_101_src.html b/tutorial/source/walkthrough/walkthrough_101_src.html
similarity index 83%
rename from tutorial/source/unpack/unpack_101_src.html
rename to tutorial/source/walkthrough/walkthrough_101_src.html
index df0873e6..6807aac9 100644
--- a/tutorial/source/unpack/unpack_101_src.html
+++ b/tutorial/source/walkthrough/walkthrough_101_src.html
@@ -15,7 +15,7 @@ <h2>Goals</h2>
       <section>
          <h2>Resources</h2>
          <p>This lesson discusses, in more depth, the same pipelines you ran in setup: <a
-               href="../setup/setup_101_src.html" class="LessonUnit">Setup 101</a>, in particular <a
+               href="../acquire/acquire_101_src.html" class="LessonUnit">Setup 101</a>, in particular <a
                href="../../../smoketest/readme.md">the smoke test pipelines</a>.</p>
          <p>Also, this lesson discusses a pipeline used for producing this tutorial: <a
                href="../../PRODUCE-PROJECTS-ELEMENTLIST.xpl">PRODUCE-PROJECTS-ELEMENTLIST.xpl</a> generates an <a
@@ -29,14 +29,31 @@ <h3>For reference</h3>
       </section>
       <section>
          <h2>Prerequisites</h2>
-         <p>Same as <a href="../setup/setup_101_src.html" class="LessonUnit">Setup 101</a>.</p>
+         <p>No prerequisites. The commentary assumes, however:</p>
+         <ul>
+            <li>You have run the acquisition, setup and test pipelines <a href="../acquire/acquire_101_src.html"
+                  class="LessonUnit">described in the first lesson set</a>, or you are willing to pretend you have done
+               so for our purposes here</li>
+            <li>You have some prior experience with either XML technologies, web publishing technologies, data modeling
+               and data exchange, or (again) you are open to learning or at least thinking about it</li>
+         </ul>
+         <p>If you fall into neither of these categories – welcome, and congratulations on your perseverence at least.
+            These pages are certainly available to be read and referenced even if you are not running any of the
+            software: as part of the resource provided (repository), they are open to anyone who finds them to be
+            useful, including for specialized purposes.</p>
+         <p>So you are also welcome to read what follows if this is your first look at XProc, or if you are not after
+            the runtime, only the ideas, or if you have some other use in mind (such as perhaps testing an XProc
+            engine?).</p>
+         <p>If you fall into this category, however, you should (one last time!) consider running some of the code after
+            all. You might be surprised at how easy and not-so-scary it really is.</p>
       </section>
       <section>
          <h2>A closer look</h2>
-         <p>If you have completed <a href="../setup/setup_101_src.html" class="LessonUnit">Setup 102</a> you have
+         <p>If you have completed <a href="../acquire/acquire_101_src.html" class="LessonUnit">Acquire 102</a> you have
             already inspected the <a href="../../../lib/readme.md">lib</a> and <a href="../../../smoketest/readme.md"
-               >smoketest</a> folders, and run pipelines you have found there. If you haven't, now is the moment to
-            catch up.</p>
+               >smoketest</a> folders, and run pipelines you have found there. If you haven't, now is a moment to catch
+            up. Even if you have decided not to install any software, please look at the pipelines we are using for the
+            purpose here.</p>
          <p>Routine code inspection can also be done on Github as well (not a bad idea in any case), not just in a copy
             of the distribution.</p>
          <p>A quick summary of what these pipelines do:</p>
@@ -56,8 +73,8 @@ <h2>A closer look</h2>
          <p>The second group of pipelines is a bit more interesting. Each of the utilities provided for in packages just
             downloaded is tested by running a smoke test.</p>
          <p>Each smoke test performs a minor task, serving as a <q>smoke test</q> inasmuch as its only aim is to
-            determine whether a simple representative process completes successfully. (When we plug in the board, can we
-            see and smell smoke?)</p>
+            determine whether a simple representative process completes successfully. (When we plug the unit in and
+            switch on the power, can we see and smell smoke?)</p>
          <ul>
             <li><a href="../../../smoketest/TEST-XPROC3.xpl">smoketest/TEST-XPROC3.xpl</a> amounts to an XProc <q>Hello
                   World</q>. In that spirit, feel free to write your own version.</li>
@@ -80,7 +97,7 @@ <h2>A closer look</h2>
       </section>
       <section>
          <h2>Walkthrough</h2>
-         <p>Each of the test pipelines exercises a simple sequence of operations. Open the XSpec file in an editor or
+         <p>Each of the test pipelines exercises a simple sequence of operations. Open any XProc file in an editor or
             viewer where you can see the tags.</p>
          <section>
             <h3>TEST-XPROC3</h3>
@@ -169,7 +186,7 @@ <h3>TEST-XSPEC</h3>
                      <q>no-op</q> in the XProc itself, it provides an occasion for a message to help trace the XProc
                   execution.</li>
             </ul>
-            <p><a href="unpack_102_src.html" class="LessonUnit">The next lesson</a> offers more detail about this
+            <p><a href="walkthrough_102_src.html" class="LessonUnit">The next lesson</a> offers more detail about this
                pipeline.</p>
          </section>
       </section>
@@ -183,16 +200,17 @@ <h2>A not-so-simple pipeline</h2>
          <p>Simplicity and flexibility together enable complexity. Once it is factored out, a complex operation can be
             managed and deployed just like a simple one, with its internal complexities masked by a simple and
             predictable interface.</p>
-         <p>One other important feature of XProc must be kept in mind: so far at least, it is all XML. We haven't seen
-            pipelines that work directly with XML data yet, much, except in the most rudimentary form (the smoke tests).
-            But most of the time that is what XProc is for. Moreover, XProc is itself in XML syntax, which makes it
-            possible to work XProc with XProc. XProc folding over on itself. Even short of of dynamically generating and
-            executing XProc (and yes that is a thing), the common ground of XML format means that with XProc working XML
-            tools, XML is always available as a force magnifier or power tool, something we can put to work again and
-            again. In XProc, errors are reported in XML. So we can capture, aggregate and index error messages in XProc.
-            In XProc, a directory file listing is provided in XML. So we have a ready way to present views of file
-            systems – the XML shows all the names and structures – as well as analyze them and access the files in them.
-            Etc.</p>
+         <p>One other important feature of XProc must be kept in mind: so far at least, it is all XML. Not yet haven't
+            looked at any real-world problems, we haven't seen pipelines that work directly with XML data yet, much,
+            except in the most rudimentary form (the smoke tests). But most of the time that is what XProc is for.
+            Moreover, XProc is itself in XML syntax, which makes it possible to work XProc with XProc. XProc folding
+            over on itself. Even short of of dynamically generating and executing XProc (and yes that can be done), the
+            common ground of XML format means that with XProc working XML tools, XML and its related ecosystem (most
+            significantl but not only XPath) is always available as a force magnifier or power tool, something we can
+            put to work again and again. In XProc, errors are reported in XML. So we can capture, aggregate and index
+            error messages in XProc. In XProc, a directory file listing is provided in XML. So we have a ready way to
+            present views of file systems – the XML shows all the names and structures – as well as analyze them and
+            access the files in them. Etc.</p>
          <p>Next, take a look at a more complex example, the prototype pipeline <a
                href="../../PRODUCE-PROJECTS-ELEMENTLIST.xpl">PRODUCE-PROJECTS-ELEMENTLIST.xpl</a>. Like the setup and
             smoke-test pipelines, this is a standalone pipeline: it acquires inputs, produces results and writes those
@@ -201,16 +219,17 @@ <h2>A not-so-simple pipeline</h2>
                <code>p:store</code> step).</p>
          <p>The result is a reference resource: an index of XProc elements used in pipelines described in this tutorial.
             For any XProc element used anywhere, the listing shows the pipelines where it appears. It also shows a list
-            of project folders in the order they are treated by this tutorial, their XProc files and with these, with
-            whatever XProc elements appear <i>first</i> (within the tutorial sequence) within that file. (Among other
-            uses this is helpful for assessing coverage of lessons.)</p>
+            of (repository) project folders in an order corresponding to their treatment (if any) in this tutorial, with
+            their XProc files. Along with these are listed whatever XProc elements appear <i>first</i> (within the
+            entire sequence up to to point) within that file. Among other uses this is helpful for assessing coverage of
+            lessons.</p>
          <p>For example, looking up <code>p:store</code> you can see all the pipelines that contain this common step. Or
             looking at the <code>oscal-convert</code> listing you can see the XProc steps introduced in that lesson.</p>
          <p>Delete or rename this result file and run the pipeline to confirm it functions properly.</p>
          <p>Consider also what other kinds of indexing might be useful. When you modify XProc or add new XProc pipelines
             to the project folders, consider running this pipeline again to update the indexes.</p>
          <p>Open the file and inspect it to get a sense of what it does. The XML syntax is verbose, but not really all
-            that frightening. The pipeline is described in more detail in the <a href="unpack_102_src.html"
+            that frightening. The pipeline is described in more detail in the <a href="walkthrough_102_src.html"
                class="LessonUnit">102 Lesson unit</a> segment.</p>
          <section>
             <h3>PRODUCE-PROJECTS-ELEMENTLIST</h3>
@@ -250,7 +269,7 @@ <h2>XML syntax, XPath and XProc</h2>
             <li>Embedded in the syntax is another syntax, <em>XPath</em>. This lightweight but powerful query language
                is a formal subset of XQuery. XPath is ubiquitous in XProc, XSLT, Schematron, XSpec etc. In XProc, the
                XPath will ordinarily be given in attributes.</li>
-            <li>Learn more about this in the <a href="unpack_102_src.html" class="LessonUnit">102 Lesson unit</a> – or
+            <li>Learn more about this in the <a href="walkthrough_102_src.html" class="LessonUnit">102 Lesson unit</a> – or
                plunge on, and pick up what you need as you go.</li>
          </ul>
       </section>
diff --git a/tutorial/source/unpack/unpack_102_src.html b/tutorial/source/walkthrough/walkthrough_102_src.html
similarity index 96%
rename from tutorial/source/unpack/unpack_102_src.html
rename to tutorial/source/walkthrough/walkthrough_102_src.html
index 5694d4a7..ea385df8 100644
--- a/tutorial/source/unpack/unpack_102_src.html
+++ b/tutorial/source/walkthrough/walkthrough_102_src.html
@@ -16,8 +16,8 @@ <h2>Goals</h2>
       </section>
       <section>
          <h2>Prerequisites</h2>
-         <p>You have done <a href="../setup/setup_101_src.html" class="LessonUnit">Setup 101</a>, <a
-               href="../setup/setup_101_src.html" class="LessonUnit">Setup 102</a> and <a href="unpack_101_src.html"
+         <p>You have done <a href="../acquire/acquire_101_src.html" class="LessonUnit">Setup 101</a>, <a
+               href="../acquire/acquire_101_src.html" class="LessonUnit">Setup 102</a> and <a href="walkthrough_101_src.html"
                class="LessonUnit">Unpack 101</a>.</p>
       </section>
       <section>
@@ -27,7 +27,7 @@ <h2>Resources</h2>
          <p>Also, the official <a href="https://xproc.org">XProc.org dashboard page</a></p>
          <p>Also, check out XProc index materials produced in this repository: <a
                href="../../../projects/xproc-doc/readme.md">XProc docs</a></p>
-         <p>And the same pipelines you ran in setup: <a href="../setup/setup_101_src.html" class="LessonUnit">Setup
+         <p>And the same pipelines you ran in setup: <a href="../acquire/acquire_101_src.html" class="LessonUnit">Setup
                101</a>.</p>
       </section>
       <section>
@@ -43,7 +43,7 @@ <h2>Learning more about XProc</h2>
       </section>
       <section>
          <h2>Details details!</h2>
-         <p>XProc pipelines described in <a href="unpack_101_src.html" class="LessonUnit">the previous lesson unit</a>
+         <p>XProc pipelines described in <a href="walkthrough_101_src.html" class="LessonUnit">the previous lesson unit</a>
             contain a few noteworthy features.</p>
          <p> To edit these files, use any XML-capable plain text editor (that is, with care, any editor at all that
             saves text files as UTF-8).</p>
diff --git a/tutorial/source/walkthrough/walkthrough_399_src.html b/tutorial/source/walkthrough/walkthrough_399_src.html
new file mode 100644
index 00000000..a45a2d89
--- /dev/null
+++ b/tutorial/source/walkthrough/walkthrough_399_src.html
@@ -0,0 +1,493 @@
+<!DOCTYPE html>
+<html xmlns="http://www.w3.org/1999/xhtml">
+   <head>
+      <title>399: XProc, XML and XDM  (the XML Data Model)</title>
+   <meta charset="utf-8"/>    </head>
+   <body data-track="learner">
+      <h1>399: XProc, XML and XDM  (the XML Data Model)</h1>
+      <p>More in depth.</p>
+      <section>
+         <h2>Goals</h2>
+         <ul>
+            <li>Consider XProc in its operational context including available <b>standards</b> and applicable
+                  <b>requirements</b>, both generalized and local</li>
+            <li>Consider the context of XProc by learning or relearning some deep XML history</li>
+            <li>Inform your capability to assess the utility and appropriateness of XProc in particular and XML in
+               general, for a given problem or domain</li>
+         </ul>
+      </section>
+      <section>
+         <h2>Resources</h2>
+         <p>The same pipelines you ran in setup: <a href="../acquire/acquire_101_src.html" class="LessonUnit">Setup
+            101</a>.</p>
+         <p>Also, <a href="https://xproc.org">XProc.org dashboard page</a></p>
+         <p>Also, XProc index materials produced in this repository: <a href="../../../projects/xproc-doc/readme.md"
+               >XProc docs</a></p>
+      </section>
+      <section>
+         <h2>Prerequisites</h2>
+         <p>Coverage here provides background information; there are no prerequisites. Prior exercises, or the practical
+            equivalent, are assumed.</p>
+      </section>
+      <section>
+         <h2>XProc as XML</h2>
+         <p>XProc is defined as an XML vocabulary. A schema for the XProc language, considered as core steps (compound
+            and atomic) plus optional community-defined steps, is referenced from the <a
+               href="https://spec.xproc.org/3.0/xproc/#ancillary-files">XProc Specification</a>. <a
+               href="https://spec.xproc.org/3.0/xproc/xproc30.rng">This RNG schema</a> is very useful.</p>
+         <p>It may often be considered gratuitous to validate XProc files against a schema, when the application (for
+            us, Morgana) must in any case take responsibility for conformance issues, as it sees fit. The reference
+            schema becomes useful if we find or suspect bugs in Morgana, but until then it need not have any direct role
+            in any runtime operation.</p>
+         <p>Nevertheless, since XProc is XML, its schema still serves as a reference and an object for querying –
+            queries whose results tell us about XProc. <a href="../../GRAB-XPROC-RESOURCES.xpl">A pipeline</a> for
+            acquiring both the RNG schema and its RNC (compact syntax) variant is provided for interest and possible
+            later use.</p>
+         <section>
+            <h3>Survey of XProc elements</h3>
+            <p>All elements defined by XProc (at time of writing) are listed in this analytical breakout.</p>
+            <p><i>However</i>, this list is provisional and intended only to offer a wider view. For the most up to date
+               information, refer to specifications. In particular, XProc 3.1 makes this list a moving target. This may
+               be out of date by the time you are able to read it.</p>
+            <p> NB also – see Erik Siegel's <a href="https://xprocref.org/index.html">XProcRef</a> indexing project for
+               more detailed summaries.</p>
+            <table>
+               <tr>
+                  <th>Function</th>
+                  <th>XProc elements / p: namespace</th>
+               </tr>
+               <tr>
+                  <td>Documentation</td>
+                  <td><code>p:documentation</code></td>
+               </tr>
+               <tr>
+                  <td>Top-level</td>
+                  <td><code>p:declare-step</code>, <code>p:library</code></td>
+               </tr>
+               <tr>
+                  <td>Imports</td>
+                  <td><code>p:import</code>, <code>p:import-functions</code></td>
+               </tr>
+               <tr>
+                  <td>Prologue</td>
+                  <td><code>p:input</code>, <code>p:output</code>, <code>p:option</code></td>
+               </tr>
+               <tr>
+                  <td>Compound steps</td>
+                  <td><code>p:group</code>, <code>p:for-each</code>, <code>p:viewport</code>, <code>p:if</code>,
+                        <code>p:choose</code> (with <code>p:when</code> and <code>p:otherwise</code>),
+                        <code>p:try</code> (with <code>p:catch</code> and <code>p:finally)</code>, <code>p:run</code>
+                     (with <code>p:run-input</code>, <code>p:run-option</code>)</td>
+               </tr>
+               <tr>
+                  <td>Atomic steps - core - XML</td>
+                  <td><code>p:add-attribute</code>, <code>p:add-xml-base</code>, <code>p:delete</code>,
+                        <code>p:filter</code>, <code>p:identity</code>, <code>p:insert</code>,
+                        <code>p:label-elements</code>, <code>p:make-absolute-uris</code>,
+                        <code>p:namespace-delete</code>, <code>p:namespace-rename</code>, <code>p:pack</code>,
+                        <code>p:rename</code>, <code>p:replace</code>, <code>p:set-attributes</code>,
+                        <code>p:uuid</code>, <code>p:unwrap</code>, <code>p:wrap-sequence</code>, <code>p:wrap</code>,
+                        <code>p:xinclude</code>, <code>p:xquery</code>, <code>p:xslt</code></td>
+               </tr>
+               <tr>
+                  <td>Atomic steps - core - zipping</td>
+                  <td><code>p:archive</code>, <code>p:archive-manifest</code>, <code>p:unarchive</code>,
+                        <code>p:uncompress</code></td>
+               </tr>
+               <tr>
+                  <td>Atomic steps - core - JSON</td>
+                  <td><code>p:json-join</code>, <code>p:json-merge</code>, <code>p:set-properties</code></td>
+               </tr>
+               <tr>
+                  <td>Atomic steps - core - plain text</td>
+                  <td><code>p:string-replace</code>, <code>p:text-count</code>, <code>p:text-head</code>,
+                        <code>p:text-join</code>, <code>p:text-replace</code>, <code>p:text-sort</code>,
+                        <code>p:text-tail</code></td>
+               </tr>
+               <tr>
+                  <td>Atomic steps - core - utility</td>
+                  <td><code>p:cast-content-type</code>, <code>p:compare</code>, <code>p:compress</code>,
+                        <code>p:count</code>, <code>p:error</code>, <code>p:hash</code>, <code>p:http-request</code>,
+                        <code>p:load</code>, <code>p:sink</code>, <code>p:split-sequence</code>, <code>p:store</code>,
+                        <code>p:www-form-urldecode</code>, <code>p:www-form-urlencode</code></td>
+               </tr>
+               <tr>
+                  <td>Atomic steps - optional - file system</td>
+                  <td><code>p:directory-list</code>, <code>p:file-copy</code>, <code>p:file-delete</code>,
+                        <code>p:file-info</code>, <code>p:file-mkdir</code>, <code>p:file-move</code>,
+                        <code>p:file-create-tempfile</code>, <code>p:file-touch</code></td>
+               </tr>
+               <tr>
+                  <td>Atomic steps - optional - validation</td>
+                  <td><code>p:validate-with-nvdl</code>, <code>p:validate-with-relax-ng</code>,
+                        <code>p:validate-with-schematron</code>, <code>p:validate-with-xml-schema</code>,
+                        <code>p:validate-with-json-schema</code></td>
+               </tr>
+               <tr>
+                  <td>Other optional steps</td>
+                  <td><code>p:os-info</code>, <code>p:os-exec</code>, <code>p:css-formatter</code>,
+                        <code>p:xsl-formatter</code>, <code>p:markdown-to-html</code></td>
+               </tr>
+               <tr>
+                  <td>Variable declaration</td>
+                  <td><code>p:variable</code></td>
+               </tr>
+               <tr>
+                  <td>Connectors</td>
+                  <td><code>p:with-input</code>, <code>p:with-option</code>, <code>p:pipe</code>,
+                        <code>p:pipeinfo</code>, <code>p:document</code>, <code>p:inline</code>,
+                     <code>p:empty</code></td>
+               </tr>
+            </table>
+         </section>
+      </section>
+      <section>
+         <h2>XML and the XDM: context and rationale</h2>
+         <p>The technologies we rely on share a common foundation in XML and XDM (the XML data model), technologies
+            developed under the auspices of the World Wide Web Consortium (W3C). For stability over a long term (years
+            and decades rather than months), we require solutions that are:</p>
+         <ul>
+            <li>Standard, non-proprietary and freely available without restriction</li>
+            <li>Consistently and repeatedly shown to be capable at scale (size/complexity)</li>
+            <li>Supported by commodity tools, easing problem of proprietary product dependencies</li>
+         </ul>
+         <p>Importantly, we need tools that are freely available to use without restriction, an important qualification
+            for this distribution, which has a prior commitment <i>not to endorse particular technological solutions to
+               any problem</i>, however posed or circumscribed. Accordingly, solutions here are not offered as
+            recommendations, but rather as stipulations of (minimum) viable functionality in tools or capabilities, and
+            not only using tools as <q>black boxes</q>, but under control and conformant to external specifications –
+            i.e., standards.</p>
+         <p>Users should keep in mind the model whereby we imagine the viability of a tools market and ecosystem that
+            enables both large and small software developers – including independent developers, academic researchers,
+            and students – to participate meaningfully, finding an appropriate value or service proposition to support
+            immediate and long-term goals. Translated, this means the tools must be capable enough for industrial use at
+            scale, while they must also <q>scale down</q> to demonstration or classroom use.</p>
+         <p>In web standards including HTML and Javascript (ECMAScript) we arguably have the beginnings of such an
+            ecosystem, while it is also contested and turbulent. Within the publishing sector more broadly and
+            intersecting with the web, the XML family of standards arguably provides the best demonstration of complete
+            or near-complete capabilities at least with respect to the harder problems of document processing.</p>
+         <ul>
+            <li>XSLT up to <a href="https://www.w3.org/TR/xslt-30/">XSLT 3.0</a> (in <a
+                  href="https://www.saxonica.com/welcome/welcome.xml">Saxon</a>)</li>
+            <li><a href="https://www.w3.org/TR/xquery-31/">XQuery</a> (in Saxon)</li>
+            <li><a href="https://github.com/Schematron">Schematron</a> (in <a href="https://github.com/schxslt/schxslt"
+                  >SchXSLT</a>, an open-source implementation in XSLT of <a href="https://schematron.com/"
+                  >Schematron</a> including the <a
+                  href="https://www.iso.org/obp/ui/#iso:std:iso-iec:19757:-3:ed-3:v1:en">ISO/IEC 19757-3</a>
+               specification</li>
+            <li><a href="https://github.com/xspec/xspec">XSpec</a>, a community-maintained XSLT-based framework for
+               test-driven development, supporting testing XSLT, XQuery and Schematron</li>
+         </ul>
+         <p>Since they are known to be highly conformant to their respective specifications as well as well tested,
+            these tools provide a useful functional baseline for evaluating other tooling that addresses the same
+            functional requirements.</p>
+         <p>They are also, relatively speaking, <i>mature</i> technologies, at least in comparison to similar
+            offerings.</p>
+         <p>And when XProc works, we also have the functional underpinnings we need for comparing - for example -
+            different XSLT implementations.</p>
+         <p>Initiated in 1996, XML continues to be generative in 2024.</p>
+      </section>
+      <section>
+         <h2>Snapshot history: an XML time line</h2>
+         <p>[TODO: complete this, or move it, or both]</p>
+         <table>
+            <thead>
+               <tr>
+                  <th>Year</th>
+                  <th>Publication</th>
+                  <th>Capabilities</th>
+                  <th>Processing frameworks</th>
+                  <th>Platforms</th>
+               </tr>
+            </thead>
+            <tbody>
+               <tr>
+                  <td>1987</td>
+                  <td>SGML (ISO-IEC 8879-1)</td>
+                  <td>parsing logic; schema validation; configurable syntax; (implicit) tree of elements and
+                     attributes</td>
+                  <td>Proprietary stacks</td>
+                  <td>Mainframes, workstations</td>
+               </tr>
+               <tr>
+                  <td>1996</td>
+                  <td>Unicode 2.0</td>
+                  <td>standard character sets</td>
+                  <td>… support for Unicode is slow to come</td>
+                  <td>PCs</td>
+               </tr>
+               <tr>
+                  <td>1998</td>
+                  <td>XML 1.0</td>
+                  <td>standard syntax</td>
+                  <td>Batch processing, shell scripts, <code>make</code></td>
+                  <td>Mainframes, workstations, PCs (x86 generation), *nix, shell, sed/awk, Perl</td>
+               </tr>
+               <tr>
+                  <td>1999</td>
+                  <td>XPath 1.0, XSLT 1.0</td>
+                  <td>basic tree querying and transformations (<q>down hill</q>); functional support for namespaces</td>
+                  <td>Web browsers? (some, sort of); standalone XSLT processors</td>
+                  <td></td>
+               </tr>
+               <tr>
+                  <td>2000</td>
+                  <td></td>
+                  <td>XML-configured software builds</td>
+                  <td>Apache Ant</td>
+                  <td>Java</td>
+               </tr>
+               <tr>
+                  <td></td>
+                  <td></td>
+                  <td></td>
+                  <td></td>
+                  <td>Perl, Python</td>
+               </tr>
+               <tr>
+                  <td></td>
+                  <td>XQuery 1.0</td>
+                  <td></td>
+                  <td></td>
+                  <td></td>
+               </tr>
+               <tr>
+                  <td></td>
+                  <td>XPath 2.0</td>
+                  <td></td>
+                  <td>Server frameworks (Apache Cocoon)</td>
+                  <td></td>
+               </tr>
+               <tr>
+                  <td>2001</td>
+                  <td>XML Schema Definition language (XDM)</td>
+                  <td>Standardizes atomic data types (foundations of XSD); namespace-based validation (RNG also offers
+                     this, 2001-2002)</td>
+                  <td></td>
+                  <td></td>
+               </tr>
+               <tr>
+                  <td>2003</td>
+                  <td></td>
+                  <td>Pipelining as a build process</td>
+                  <td>Apache Ant</td>
+                  <td>Java</td>
+               </tr>
+               <tr>
+                  <td>2003-2004</td>
+                  <td>W3C Document Object Model (DOM)</td>
+                  <td>API for HTML and XML documents</td>
+                  <td></td>
+                  <td></td>
+               </tr>
+               <tr>
+                  <td>2005</td>
+                  <td><q>The XML data model</q> (W3C)</td>
+                  <td>An essay</td>
+                  <td></td>
+                  <td></td>
+               </tr>
+               <tr>
+                  <td>2006</td>
+                  <td>XProc 1.0 Requirements</td>
+                  <td></td>
+                  <td></td>
+                  <td>Proof-of-concept demonstrations</td>
+               </tr>
+               <tr>
+                  <td>2007</td>
+                  <td>XSLT 2.0</td>
+                  <td>Transformations (<q>up hill</q>) including grouping, string processing, pipelining</td>
+                  <td></td>
+                  <td></td>
+               </tr>
+               <tr>
+                  <td></td>
+                  <td>XDM (XPath/XQuery data model)</td>
+                  <td>Unifying a data model for XPath, XSLT and XQuery</td>
+                  <td></td>
+                  <td>Client- and server-side XML processing stacks</td>
+               </tr>
+               <tr>
+                  <td></td>
+                  <td></td>
+                  <td></td>
+                  <td>XQuery+XSLT in eXist-db or BaseX (XQuery engines)</td>
+                  <td></td>
+               </tr>
+               <tr>
+                  <td></td>
+                  <td>XPath 3.0</td>
+                  <td></td>
+                  <td></td>
+                  <td></td>
+               </tr>
+               <tr>
+                  <td></td>
+                  <td>XPath 3.1</td>
+                  <td>Higher-order functions, map and array objects</td>
+                  <td></td>
+                  <td></td>
+               </tr>
+               <tr>
+                  <td>2010</td>
+                  <td>XProc 1.0</td>
+                  <td></td>
+                  <td></td>
+                  <td></td>
+               </tr>
+               <tr>
+                  <td>2017</td>
+                  <td>XSLT 3.0/3.1</td>
+                  <td>JSON harmonization, functions as arguments</td>
+                  <td></td>
+                  <td></td>
+               </tr>
+               <tr>
+                  <td></td>
+                  <td>XProc 3.0</td>
+                  <td>Easier syntax, plus adding support for JSON and other content types</td>
+                  <td></td>
+                  <td></td>
+               </tr>
+               <tr>
+                  <td>2022</td>
+                  <td>Unicode 15.0</td>
+                  <td></td>
+                  <td></td>
+                  <td></td>
+               </tr>
+            </tbody>
+         </table>
+         <p>The technologies have been in constant use over this period.</p>
+         <p>Historically, the requirements of processing frameworks have often been met by software developers' build
+            utilities (for example, GNU <code>make</code> or Apache Ant). This is not an accident: in certain respects,
+            a publishing framework can be considered as a <q>documentary build</q>, to be run at intervals corresponding to the publishing cycle with its proof runs.</p>
+      </section>
+      <section>
+         <h2>XPath</h2>
+         <p>Like other XDM-based technologies, XProc embeds and incorporates XPath, an expression language for XML.
+            XPath 3.0 is a functional language in its own right, although not designed for end-to-end processing of
+            encoded source data into encoded results, but only for certain critical operations that ordinarily need to
+            be performed within such end-to-end processing. Importantly, XPath is defined not in terms of any data
+            notation (such as XML syntax or any other) but rather against an <i>abstract data object</i>, namely an <a
+               href="https://www.w3.org/TR/xpath-datamodel/">XDM</a> instance (XML data model), a putative information
+            object that may be provided to the system by parsing an XML (syntax) instance, or by other means. As the
+            query language for <a href="https://www.w3.org/TR/xpath-datamodel/">XDM</a> and the basis for XQuery, <a
+               href="https://www.w3.org/TR/xpath-31/">XPath</a> is the <q>other half</q> of the data model, which any
+            architect of a system using this technology must know. Learning XPath equips you mentally for dealing with
+            the XDM in XQuery, XSLT, XProc or anywhere you find it.</p>
+         <p>For those not already familiar with XPath, on line resources can be helpful. Keep in mind that <a
+               href="https://www.w3.org/TR/xpath-31/">XPath 3.1</a> outstrips earlier versions of the language in many
+            important respects (supporting map and function objects with higher-order functions, among other
+            features).</p>
+         <section>
+            <h3>Documents and data</h3>
+            <p>One of the more important features of XPath and the XDM is that they are designed not only to meet needs
+               for the representation and transmission of structured data. A specialized class of data formats has
+               evolved that represent information in ways that are not <q>unstructured</q>, but that contrast with more
+               common or usual structures of data formats, whether they be tabular data, serialization formats for
+               object models, or some other regular (formalized and codified) arrangement for purposes of
+               machine-readability. One might say <q>common</q> or <q>usual</q> with reservation, since of course
+               documents are not uncommon where they are common. The prevalence of so-called structured data in digital
+               systems may tell us more about the limits of those systems than it does about information in general.</p>
+            <p>We see a great deal of structured data these days if only because it is so easy to make structured data
+               with machines, and we now have the machines. What remains difficult is to translate what has not been
+               created by a machine, into a form that a machine can <q>recognize</q>, or rather into a form we can
+               recognize in and with the machine, without mishandling it and distorting it. Since machines do not
+               recognize anything (nothing is <q>mishandling</q> to them), what this often reduces to in practice is
+               deciding how to agree on a <b>representation</b> for information that any creator and any consumer can
+               recognize and work with, without seeing the information first. In itself this is a formidable
+               challenge.</p>
+            <p>So documents are called <q>unstructured</q> but they might better be called <q>relatively irregular</q>,
+               meaning not that they have no structure, but that each one is structured in itself, and moreover, likely
+               to be incompatible or not fully compatible with encodings designed to capture other structures.</p>
+            <p>And to the extent this is the case, any encoding capable of describing documents must have the capability
+               of supporting each document's own distinctive structure and organization, whether that be due to its
+               family (what is called a <b>document type</b>) or an expression of its own intrinsic logic. The format
+               must be not only structured, but <i>structurable</i>, and its structures must to some extent be capable
+               of self-description – combining data with metadata.</p>
+            <p>And this is to give no consideration to the fact that these structures can be described at <i>multiple
+                  levels</i> of generality or specificity with regard to either their supposed semantics, or their
+               configuration in operation.</p>
+            <p>Documentary data formats especially markup formats are designed to work in this in-between space.</p>
+            <p>And so we get XPath - a query syntax which permits working with an organized structure of a particular
+               kind (an <i>XDM document tree</i>), which in turn is designed for handling the combination of <i>highly
+                  regular</i> and <i>quite irregular</i> data structures that characterize information sets we (loosely)
+               call <b>documentary</b>.</p>
+            <p>A definition for what is a document is out of scope for this tutorial – an interesting topic but not only
+               a technical one.</p>
+         </section>
+         <section>
+            <h3>XPath illustrative examples</h3>
+            <p>This is not the place to learn XPath, but a selection of XPath expressions can offer a hint of its
+               capabilities.</p>
+            <table>
+               <thead>
+                  <tr>
+                     <th>XPath</th>
+                     <th>Returns</th>
+                     <th>XPath long (explicit) notation</th>
+                  </tr>
+               </thead>
+               <tbody>
+                  <tr>
+                     <td><code>/html</code></td>
+                     <td>An XML document root (top-level) element named <code>html</code> (subject to namespace
+                        resolution)</td>
+                     <td><code>/child::html</code></td>
+                  </tr>
+                  <tr>
+                     <td><code>//p</code></td>
+                     <td>All the elements named <code>p</code> in the document</td>
+                     <td><code>/descendant-or-self::element()/ child::p</code></td>
+                  </tr>
+                  <tr>
+                     <td><code>//seg[@type='null']</code></td>
+                     <td>All the elements named <code>seg</code> with an attribute <code>type</code> with value
+                           <code>null</code></td>
+                     <td><code>/descendant-or-self::element()/ child::seg[attribute::type='null']</code></td>
+                  </tr>
+                  <tr>
+                     <td><code>/*</code></td>
+                     <td>Any document (rather, any element at the top of a document) - <code>*</code> is a wildcard
+                        character</td>
+                     <td><code>/child::element()</code></td>
+                  </tr>
+                  <tr>
+                     <td><code>/section[exists(.//table)]</code></td>
+                     <td>An element inside the top-level element, named <code>section</code>, that contains a
+                           <code>table</code> element anywhere inside it</td>
+                     <td><code>/child::section[exists(self::node()/ descendant-or-self::element()/ child::table)]</code></td>
+                  </tr>
+                  <tr>
+                     <td><code>/descendant::p[10]</code></td>
+                     <td>The tenth <code>p</code> element in the document</td>
+                     <td><code>/descendant::p[position() eq 10]</code></td>
+                  </tr>
+                  <tr>
+                     <td><code>//p[10]</code></td>
+                     <td>All <code>p</code> elements, that are the tenth <code>p</code> inside their respective
+                        parents</td>
+                     <td><code>/descendant-or-self::element()/ child::p[position() eq 10]</code></td>
+                  </tr>
+                  <tr>
+                     <td><code>//section[count(.//p) gt 10]</code></td>
+                     <td>All <code>section</code> elements that contain more than 10 <code>p</code> elements, at any
+                        depth</td>
+                     <td><code>/child::section[count(self::node()/ descendant-or-self::element()/ child::p) gt
+                        10]</code></td>
+                  </tr>
+               </tbody>
+            </table>
+            <p>Where do you find XPath? Any <code>select</code> or <code>match</code> expression in XSLT or XProc shows
+               an example. XPath also constitutes the core of XQuery.</p>
+         </section>
+      </section>
+      <section>
+         <h2>Exercise: Discussion board</h2>
+         <p>Create or contribute to a Github discussion board offering perspective or (especially!) relevant information
+            or experience on any of the larger questions.</p>
+      </section>
+   </body>
+</html>
\ No newline at end of file
diff --git a/tutorial/source/walkthrough/walkthrough_401_src.html b/tutorial/source/walkthrough/walkthrough_401_src.html
new file mode 100644
index 00000000..4132b114
--- /dev/null
+++ b/tutorial/source/walkthrough/walkthrough_401_src.html
@@ -0,0 +1,145 @@
+<!DOCTYPE html>
+<html xmlns="http://www.w3.org/1999/xhtml">
+   <head>
+      <title>401 - XSLT, forward and back</title>
+   <meta charset="utf-8"/>    </head>
+   <body data-track="learner">
+      <h1>401 - XSLT Forward and Back</h1>
+      <p>What is this XSLT?</p>
+      <p>Read this page if you are a beginner, or an expert in XSLT, or if you plan never to use it.</p>
+      <section>
+         <h2>Goals</h2>
+         <ul>
+            <li>If you don't know XSLT, helps you understand what it is and what it does</li>
+            <li>If you know XSLT, understand something more about how it fits with XProc</li>
+         </ul>
+      </section>
+      <section>
+         <h2>Resources</h2>
+         <p>XSLT links!</p>
+         <section>
+            <h3>XSLT 1.0 and XPath 1.0</h3>
+         </section>
+         <section>
+            <h3>XSLT 2.0 and XQuery 1.0</h3>
+         </section>
+         <section>
+            <h3>XSLT 3.0, XQuery 3.0, XPath 3.1</h3>
+         </section>
+      </section>
+      <section>
+         <h2>Prerequisites</h2>
+         <p>You have run and inspected pipelines mentioned earlier, most especially <a
+               href="../../PRODUCE-PROJECTS-ELEMENTLIST.xpl">PRODUCE-PROJECTS-ELEMENTLIST.xpl</a>, which contains
+               <code>p:xslt</code> steps.</p>
+         <p>You have inspected XSLT files (standalone transformations or <em>stylesheets</em>), to be found more or less
+            anywhere in this repository, especially directories named <code>src</code>.</p>
+      </section>
+      <section>
+         <h2>XSLT: XSL (XML Stylesheet Language) Transformations</h2>
+         <p>XSLT has a long and checkered reputation and a history that may be even more amazing.</p>
+         <p>Chances are good that if you are not current on the latest version of this technology, you have little idea
+            of what we are talking about, as it may have changed quite a bit (and even despite external appearances)
+            since you last saw it.</p>
+         <p>Users who last used XSLT 1.0 and even 2.0, in particular, can consider their knowledge out of date until
+            they have taken a look at XSLT 3.0.</p>
+         <p>Programmers can think of XSLT as a domain-specific language (DSL) or fourth-generation language (4GL)
+            designed for the purpose of manipulating data structures suitable for documents and messages as well as for
+            structured data sets. As such, XSLT is highly generalized and abstract and can be applied to a very broad
+            range of problems. Its main distinguishing feature among similar languages (which tend to be functional
+            languages such as Scala and Scheme) is that it is optimized for use specifically with XML-based data
+            formats, offering well-defined handling of information sets expressed in XML, while the language itself uses
+            XML syntax, affording nice composability, reflection and code generation capabilities. XSLT's processing
+            model is both broadly applicable, and workable in a range of environments including client software or
+            within encapsulated, secure software configurations and deployments.</p>
+         <p>If your XSLT is strong enough, you don't need XProc, or not much. But as a functional language, XSLT is best
+            used in a functionally pure way that does not interact with the system: no <q>side effects</q>. This is
+            related to its definitions of conformant processing (X inputs produce Y outputs) and the determinism, based
+            in mathematical formalisms, that underlies this idea of conformance. However one cost of mathematical purity
+            is that operations that do interact with stateful externalities – things such as reading and writing files –
+            are not in XSLT's <q>comfort zone</q>. It easily defines what a new structure A' should look like for any
+            given structure A. But how A is first acquired or what we do once we have determined A', is less clear, and
+            left up to the processor to handle, as an interface, starting with an XSLT transformation's nominal
+               <em>source</em> and (primary) <em>result</em>. Often, this gap has been bridged by extended functionality
+            provided by leading processors. Does your processor read and parse XML files off the file system? Can it be
+            connected to upstream processes in different ways? Can it use HTTP <code>GET</code> and <code>PUT</code>?
+            The answer may be Yes to any or all of these. Throughout its history, XSLT in later versions was also
+            extended in this direction, with features such as the <code>collection()</code> function,
+               <code>xsl:result-document</code>, <code>doc-available()</code> and other features we don't need if we are
+            using XProc.</p>
+         <p>Then too, XSLT is commonly run from scripts, in web hosting environments, and indeed from XQuery. Or you
+            might be able to configure your desktop software (Editor or IDE) to run your XSLT, or indeed acquire
+            specialized software just for reading and filtering collections or managing sets of file outputs in
+            XSLT-based workflows.</p>
+         <p>It is difficult not to think, however, that a gentler approach is also possible to the range of problems
+            related to making XSLT accessible in any environment – one that offers the feature set and flexibility we
+            need, but with less overhead, especially with regard to routine chores like designating sets of inputs and
+            outputs, or sequencing operations. The principle of Least Power may well apply here: it saves our present
+            and our future selves effort if we can arrange and manage to do things less. XProc lets us do less.</p>
+         <p>XProc lets us use XSLT when we must, but also keeps routine and simple things both simple and consistent,
+            without requiring much overhead. But it adapts itself well to new requirements as they become more
+            complicated. Ultimately, it spares the XSLT developer the problem of having to design, build and test
+            something like XProc.</p>
+         <section>
+            <h3>Running XSLT without XProc</h3>
+            <p>As a standard and an externally-specified technology, XSLT can in principle be implemented on any
+               platform, but the leading XSLT implementation for some years has been Saxon, produced by Saxonica of
+               Reading, England. Saxon has achieved market share and developer support on a record of
+               strictly-conformant, performant applications, deployed as an open-source software product free for
+               developers to use and integrate. (While doing this, Saxonica also has related product offerings including
+               optimized processor for those who choose to support it.)</p>
+            <p>Download and run Saxon to apply XSLT to XML and other inputs, without XProc.</p>
+         </section>
+      </section>
+      <section>
+         <h2>Learning XSLT the safer way</h2>
+         <p>If setting out to learn XSLT, pause to read the following list of things to which you should give early
+            attention, in order:</p>
+         <ol>
+            <li>Namespaces in XML and XSLT: names, name prefixes, unprefixed names and the
+                  <code>xpath-default-namespace</code> setting (not available until XSLT 2.0)</li>
+            <li>Templates and modes in XSLT: template matching, <code>xsl:apply-templates</code>, built-in templates,
+               and using modes to configure default behaviors when no template matches</li>
+            <li>XPath, especially absolute and relative location paths: start easy and work up</li>
+         </ol>
+         <p>Only one of these topics does not also apply to XProc.</p>
+      </section>
+      <section>
+         <h2>XProc without XSLT?</h2>
+         <p>XProc does not require XSLT absolutely, even if XSLT is indispensable for some of XProc libraries, including
+            those in this repository.</p>
+         <p>How could we do without it?</p>
+         <ul>
+            <li>Using XQuery any time queries get complicated</li>
+            <li>Use XProc where possible, for example steps that support matches on patterns? E.g.
+               <code>p:insert</code>, <code>p:label-elements</code> and <code>p:add-attribute</code></li>
+            <li>Reliance on iterators and <code>p:viewport</code></li>
+            <li>Much smarter (declarative, data-centric) HTML or other dialect in the application space?</li>
+         </ul>
+         <p>Chances are, there is a limit. One thing XSLT does better than almost any comparable technology is support
+            generalized or granular mappings between vocabularies.</p>
+         <p>So not only creating, but also consuming HTML, is the place we begin with XSLT. But since it is also very
+            fine for other vocabulary mappings in the middle and back, it becomes indispensable almost as soon as it is
+            available for use.</p>
+      </section>
+      <section>
+         <h2>XProc, XDM (the XML data model) and the standards stack</h2>
+         <p>Another critical consideration is whether and to what extent XProc and XSLT introduce unwanted dependencies,
+            which make them strategically not a good choice (or not a good choice for everyone) at least in comparison
+            to alternatives. These are standards in every way including nominally - emerging as the work of
+            organizations such as W3C and ISO, while not escaping a reputation as <q>boutique</q> or <q>niche</q>
+            technologies. Yet alternative models – whether to go with the big guys, or rely on forests of Javascript
+            libraries, or support a bespoke Markdown-based stack – have not all fared very well either. Often scorned,
+            XSLT has a reputation for projects migrating away from it as much as towards it. Yet look closely, and when
+            problems arise, XSLT is never the issue by itself. Often the question is, were you even using the right
+            tool? one way is to be in the sweet spot (and there is a sweet spot) of document processing at scale, but
+            this is not definitive. Sometimes the question is, are you actually fitting the capabilities of the
+            processing model to the problem at hand. Too often, that fit happens by accident.</p>
+         <p>So where has XML-based processing been not only tenable but rewarding over the long term? Interestingly, its
+            success is to be found often in projects that have survived across more than one system over time, that have
+            grown from one system into another, and that have morphed and adapted and grown new limbs. (Pubmed Central
+            comes to mind. But what about Optical Society? PLOS?) In other words, look at them today and you do not see
+            the same system as you would have only five years ago.</p>
+      </section>
+   </body>
+</html>
\ No newline at end of file
diff --git a/tutorial/tutorial-preview.html b/tutorial/tutorial-preview.html
index 2f6be584..18163c39 100644
--- a/tutorial/tutorial-preview.html
+++ b/tutorial/tutorial-preview.html
@@ -34,10 +34,10 @@
    <body>
       <div class="toc">
          <div class="lesson"
-              id="toc-setup"
-              name="setup">
+              id="toc-acquire"
+              name="acquire">
             <div class="unit observer"
-                 id="toc-setup_101"
+                 id="toc-acquire_101"
                  data-track="observer">
                <h1>101: Project setup and installation<span class="wordcount okay"> (~1315)</span>
                </h1>
@@ -67,7 +67,7 @@ <h3>Tweaks</h3>
                </div>
             </div>
             <div class="unit maker"
-                 id="toc-setup_102"
+                 id="toc-acquire_102"
                  data-track="maker">
                <h1>102: Examining the setup<span class="wordcount okay"> (~749)</span>
                </h1>
@@ -91,7 +91,7 @@ <h2>For consideration</h2>
                </div>
             </div>
             <div class="unit learner"
-                 id="toc-setup_599"
+                 id="toc-acquire_599"
                  data-track="learner">
                <h1>599: Meeting XProc<span class="wordcount okay"> (~351)</span>
                </h1>
@@ -104,12 +104,12 @@ <h2>Declarative markup in action</h2>
             </div>
          </div>
          <div class="lesson"
-              id="toc-unpack"
-              name="unpack">
+              id="toc-walkthrough"
+              name="walkthrough">
             <div class="unit observer"
-                 id="toc-unpack_101"
+                 id="toc-walkthrough_101"
                  data-track="observer">
-               <h1>101: Unpacking XProc 3.0<span class="wordcount over"> (~2361)</span>
+               <h1>101: Unpacking XProc 3.0<span class="wordcount over"> (~2518)</span>
                </h1>
                <div>
                   <h2>Goals</h2>
@@ -155,7 +155,7 @@ <h2>Learning more about XProc</h2>
                </div>
             </div>
             <div class="unit maker"
-                 id="toc-unpack_102"
+                 id="toc-walkthrough_102"
                  data-track="maker">
                <h1>102: XProc fundamentals<span class="wordcount okay"> (~1316)</span>
                </h1>
@@ -197,7 +197,7 @@ <h3>Syntax tips</h3>
                </div>
             </div>
             <div class="unit learner"
-                 id="toc-unpack_399"
+                 id="toc-walkthrough_399"
                  data-track="learner">
                <h1>399: XProc, XML and XDM  (the XML Data Model)<span class="wordcount over"> (~2107)</span>
                </h1>
@@ -236,7 +236,7 @@ <h2>Exercise: Discussion board</h2>
                </div>
             </div>
             <div class="unit learner"
-                 id="toc-unpack_401"
+                 id="toc-walkthrough_401"
                  data-track="learner">
                <h1>401 - XSLT Forward and Back<span class="wordcount okay"> (~1393)</span>
                </h1>
@@ -323,7 +323,7 @@ <h3>Intercepting errors</h3>
             <div class="unit maker"
                  id="toc-oscal-convert_102"
                  data-track="maker">
-               <h1>102: Hands on data conversions<span class="wordcount okay"> (~1438)</span>
+               <h1>102: Hands on data conversions<span class="wordcount okay"> (~1526)</span>
                </h1>
                <div>
                   <h2>Goals</h2>
@@ -517,10 +517,10 @@ <h2>Produce a new project and document it with a tutorial</h2>
          </div>
       </div>
       <section class="lesson"
-               id="setup"
-               name="setup">
+               id="acquire"
+               name="acquire">
          <section class="unit observer"
-                  id="setup_101"
+                  id="acquire_101"
                   data-track="observer">
             <h1>101: Project setup and installation</h1>
             <section>
@@ -674,7 +674,7 @@ <h3>Tweaks</h3>
             </section>
          </section>
          <section class="unit maker"
-                  id="setup_102"
+                  id="acquire_102"
                   data-track="maker">
             <h1>102: Examining the setup</h1>
             <section>
@@ -783,7 +783,7 @@ <h2>For consideration</h2>
             </section>
          </section>
          <section class="unit learner"
-                  id="setup_599"
+                  id="acquire_599"
                   data-track="learner">
             <h1>599: Meeting XProc</h1>
             <section>
@@ -817,10 +817,10 @@ <h2>Declarative markup in action</h2>
          </section>
       </section>
       <section class="lesson"
-               id="unpack"
-               name="unpack">
+               id="walkthrough"
+               name="walkthrough">
          <section class="unit observer"
-                  id="unpack_101"
+                  id="walkthrough_101"
                   data-track="observer">
             <h1>101: Unpacking XProc 3.0</h1>
             <section>
@@ -832,7 +832,7 @@ <h2>Goals</h2>
             </section>
             <section>
                <h2>Resources</h2>
-               <p>This lesson discusses, in more depth, the same pipelines you ran in setup: <a href="../setup/setup_101_src.html"
+               <p>This lesson discusses, in more depth, the same pipelines you ran in setup: <a href="../acquire/acquire_101_src.html"
                      class="LessonUnit">Setup 101</a>, in particular <a href="../../../smoketest/readme.md">the smoke test pipelines</a>.</p>
                <p>Also, this lesson discusses a pipeline used for producing this tutorial: <a href="../../PRODUCE-PROJECTS-ELEMENTLIST.xpl">PRODUCE-PROJECTS-ELEMENTLIST.xpl</a> generates an <a href="../../sequence/element-directory.md">index to XProc in this repository</a>
                </p>
@@ -845,15 +845,27 @@ <h3>For reference</h3>
             </section>
             <section>
                <h2>Prerequisites</h2>
-               <p>Same as <a href="../setup/setup_101_src.html"
-                     class="LessonUnit">Setup 101</a>.</p>
+               <p>No prerequisites. The commentary assumes, however:</p>
+               <ul>
+                  <li>You have run the acquisition, setup and test pipelines <a href="../acquire/acquire_101_src.html"
+                        class="LessonUnit">described in the first lesson set</a>, or you are willing to pretend you have done
+               so for our purposes here</li>
+                  <li>You have some prior experience with either XML technologies, web publishing technologies, data modeling
+               and data exchange, or (again) you are open to learning or at least thinking about it</li>
+               </ul>
+               <p>If you fall into neither of these categories – welcome, and congratulations on your perseverence at least.
+            These pages are certainly available to be read and referenced even if you are not running any of the
+            software: as a resource, this means they are open to anyone who finds them to be useful, including for
+            specialized purposes.</p>
+               <p>So you are also welcome to read what follows if this is your first look at XProc.</p>
             </section>
             <section>
                <h2>A closer look</h2>
-               <p>If you have completed <a href="../setup/setup_101_src.html"
-                     class="LessonUnit">Setup 102</a> you have
-            already inspected the <a href="../../../lib/readme.md">lib</a> and <a href="../../../smoketest/readme.md">smoketest</a> folders, and run pipelines you have found there. If you haven't, now is the moment to
-            catch up.</p>
+               <p>If you have completed <a href="../acquire/acquire_101_src.html"
+                     class="LessonUnit">Acquire 102</a> you have
+            already inspected the <a href="../../../lib/readme.md">lib</a> and <a href="../../../smoketest/readme.md">smoketest</a> folders, and run pipelines you have found there. If you haven't, now is a moment to catch
+            up. Even if you have decided not to install any software, please look at the pipelines we are using for the
+            purpose here.</p>
                <p>Routine code inspection can also be done on Github as well (not a bad idea in any case), not just in a copy
             of the distribution.</p>
                <p>A quick summary of what these pipelines do:</p>
@@ -1004,7 +1016,7 @@ <h3>TEST-XSPEC</h3>
                   execution.</li>
                   </ul>
                   <p>
-                     <a href="unpack_102_src.html"
+                     <a href="walkthrough_102_src.html"
                         class="LessonUnit">The next lesson</a> offers more detail about this
                pipeline.</p>
                </section>
@@ -1045,7 +1057,7 @@ <h2>A not-so-simple pipeline</h2>
                <p>Consider also what other kinds of indexing might be useful. When you modify XProc or add new XProc pipelines
             to the project folders, consider running this pipeline again to update the indexes.</p>
                <p>Open the file and inspect it to get a sense of what it does. The XML syntax is verbose, but not really all
-            that frightening. The pipeline is described in more detail in the <a href="unpack_102_src.html"
+            that frightening. The pipeline is described in more detail in the <a href="walkthrough_102_src.html"
                      class="LessonUnit">102 Lesson unit</a> segment.</p>
                <section>
                   <h3>PRODUCE-PROJECTS-ELEMENTLIST</h3>
@@ -1085,7 +1097,7 @@ <h2>XML syntax, XPath and XProc</h2>
                   <li>Embedded in the syntax is another syntax, <em>XPath</em>. This lightweight but powerful query language
                is a formal subset of XQuery. XPath is ubiquitous in XProc, XSLT, Schematron, XSpec etc. In XProc, the
                XPath will ordinarily be given in attributes.</li>
-                  <li>Learn more about this in the <a href="unpack_102_src.html"
+                  <li>Learn more about this in the <a href="walkthrough_102_src.html"
                         class="LessonUnit">102 Lesson unit</a> – or
                plunge on, and pick up what you need as you go.</li>
                </ul>
@@ -1105,7 +1117,7 @@ <h2>Learning more about XProc</h2>
             </section>
          </section>
          <section class="unit maker"
-                  id="unpack_102"
+                  id="walkthrough_102"
                   data-track="maker">
             <h1>102: XProc fundamentals</h1>
             <p>
@@ -1120,9 +1132,9 @@ <h2>Goals</h2>
             </section>
             <section>
                <h2>Prerequisites</h2>
-               <p>You have done <a href="../setup/setup_101_src.html"
-                     class="LessonUnit">Setup 101</a>, <a href="../setup/setup_101_src.html"
-                     class="LessonUnit">Setup 102</a> and <a href="unpack_101_src.html"
+               <p>You have done <a href="../acquire/acquire_101_src.html"
+                     class="LessonUnit">Setup 101</a>, <a href="../acquire/acquire_101_src.html"
+                     class="LessonUnit">Setup 102</a> and <a href="walkthrough_101_src.html"
                      class="LessonUnit">Unpack 101</a>.</p>
             </section>
             <section>
@@ -1134,7 +1146,7 @@ <h2>Resources</h2>
                </p>
                <p>Also, check out XProc index materials produced in this repository: <a href="../../../projects/xproc-doc/readme.md">XProc docs</a>
                </p>
-               <p>And the same pipelines you ran in setup: <a href="../setup/setup_101_src.html"
+               <p>And the same pipelines you ran in setup: <a href="../acquire/acquire_101_src.html"
                      class="LessonUnit">Setup
                101</a>.</p>
             </section>
@@ -1151,7 +1163,7 @@ <h2>Learning more about XProc</h2>
             </section>
             <section>
                <h2>Details details!</h2>
-               <p>XProc pipelines described in <a href="unpack_101_src.html"
+               <p>XProc pipelines described in <a href="walkthrough_101_src.html"
                      class="LessonUnit">the previous lesson unit</a>
             contain a few noteworthy features.</p>
                <p> To edit these files, use any XML-capable plain text editor (that is, with care, any editor at all that
@@ -1277,7 +1289,7 @@ <h3>Syntax tips</h3>
             </section>
          </section>
          <section class="unit learner"
-                  id="unpack_399"
+                  id="walkthrough_399"
                   data-track="learner">
             <h1>399: XProc, XML and XDM  (the XML Data Model)</h1>
             <p>More in depth.</p>
@@ -1293,7 +1305,7 @@ <h2>Goals</h2>
             </section>
             <section>
                <h2>Resources</h2>
-               <p>The same pipelines you ran in setup: <a href="../setup/setup_101_src.html"
+               <p>The same pipelines you ran in setup: <a href="../acquire/acquire_101_src.html"
                      class="LessonUnit">Setup
             101</a>.</p>
                <p>Also, <a href="https://xproc.org">XProc.org dashboard page</a>
@@ -1877,7 +1889,7 @@ <h2>Exercise: Discussion board</h2>
             </section>
          </section>
          <section class="unit learner"
-                  id="unpack_401"
+                  id="walkthrough_401"
                   data-track="learner">
             <h1>401 - XSLT Forward and Back</h1>
             <p>What is this XSLT?</p>
@@ -2245,14 +2257,17 @@ <h2>Designating an input at runtime by binding input ports</h2>
                <section>
                   <h3>Binding to input ports vs p:load steps</h3>
                   <p>XProc offers two ways to acquire data from outside the pipeline: by using <code>p:load</code> or by
-               binding inputs to an input port using p:input/p:document. These are somewhat different in operation -
-               errors produced by p:load cannot be detected until the pipeline is run, whereas failures with p:input
-               should be detected when the pipeline itself is loaded and compiled (i.e. during <em>static analysis</em>).
-               Apart from this distinction the two
-               approaches have similar effects – whether to use one or the other depends often on how you expect the pipeline to
-               be used and distributed, not on whether it works.</p>
-                  <p>For example, if you wish to acquire more than a single document that the caller cannot override, make a
-               step like this:</p>
+               binding inputs to an input port using <code>p:input/p:document</code>. These are somewhat different in
+               operation - errors produced by <code>p:load</code> cannot be detected until the pipeline is run, whereas
+               failures with <code>p:input</code> should be detected when the pipeline itself is loaded and compiled
+               (i.e. during <em>static analysis</em>), and processors may be able to apply different kinds of exception
+               handling, fallbacks or support for redirects. (As always you can try, test and determine for yourself.)
+               Apart from this distinction the two approaches have similar effects – whether to use one or the other
+               depends often on how you expect the pipeline to be used and distributed, not on whether it works.</p>
+                  <p>Although one distinction is that p:document appears on input ports, which can be overridden, this does
+               not mean that p:document can't be essentially <q>private</q> to a pipeline or pipeline step. For example,
+               if you wish to acquire more than a single document, without p:load, known in advance (i.e. the file names
+               can be hard-coded), make a step like this:</p>
                   <pre>&lt;p:identity&gt;
   &lt;p:with-input&gt;
     &lt;p:document href="..."/&gt;
@@ -2262,7 +2277,7 @@ <h3>Binding to input ports vs p:load steps</h3>
 &lt;p:identity&gt;</pre>
                   <p>This binds the documents to the input of an <b>identity</b> step (which supports a sequence), without
                exposing an input port in the main pipeline.</p>
-                  <p>A more dynamic approach would be to acquire a list of file names, for example:</p>
+                  <p>A more dynamic approach is sometimes useful: first, acquire a list of file names, for example:</p>
                   <pre>&lt;p:input port="source"&gt;
    &lt;p:inline&gt;
       &lt;FILELIST&gt;
@@ -2286,6 +2301,8 @@ <h3>Binding to input ports vs p:load steps</h3>
                override the second approach by providing a different FILELIST document. Alternatively such a FILELIST
                can be referenced instead of included … <code>p:document href="the-filelist.xml</code>, providing us a
                resource that we can maintain separately.</p>
+                  <p>This makes the second approach especially appealing if the file list can be derived from some kind of
+               metadata resource or, indeed, <code>p:directory-list</code>….</p>
                </section>
             </section>
             <section>