Lets start with a simpler test case; "w1" in the test data of the second post:

1
2
3
4
5
6
7

let w1 = I 1

== console output =>
Input 1 = w1

== XML output =>
<Wires.Input v1="1" />

What code is sufficient to output this structure, working only from the Reflection data of "typeof<Wires>"?

To refresh our memory of the type definitions:

1
2
3
4
5
6
7

type NodeIndex = int

type Wires =
    Complete 
  | Input of NodeIndex    // Input Terminal with wire coming out.
  | Output of NodeIndex   // Output terminal with wire coming in.
  | Thru of NodeIndex * NodeIndex

"NodeIndex" is simply an alias for "int", which is an alias for "System.Int32"; internally this is the same as:

1
2
3
4
5

type Wires =
    Complete 
  | Input of System.Int32
  | Output of System.Int32
  | Thru of System.Int32 * System.Int32

I know that the top-level entity is a DU (discriminated union), and that what is wanted is an XmlDocument from namespace System.XML, [link:msdn2.microsoft.com]
All the XML types we will work with are from that namespace.
We will use Reflection, both the general .Net Reflection as well as F# extensions.

For clarity, I define short aliases to those namespaces (rather than simply using "open" on each):
module SR = System.Reflection
module X = System.Xml
module FR = Microsoft.FSharp.Reflection
module FV = Microsoft.FSharp.Reflection.Value

Given that, here is the specification of the function at the top of the translation to XML:
/// Build a document with du instance as its main element.
let buildDocForDU (rootDu) :X.XmlDocument = ...

What will this function do? This function creates an XML Document, and then creates an XML Element to be the root element in that document. Since we know that a DU might reference other DUs, the DU => XML Element creation is subcontracted to a (recursive) function. A natural design recurses down to the smallest detail, which then passes back its result, which gets aggregated into larger results as passed back up the function stack. One wrinkle: XML Elements and other XML Nodes can only be created (in Microsoft's implementation) by the containing XML Document, so we have to pass a "doc" parameter down through all the functions. I've said a lot; here is the resultant code:

1
2
3
4
5
6
7
8
9
10
11

  /// Build an XmlNode for a discriminated union instance.
  /// REQUIRE: du is a discriminated union instance.
  /// du has 'tag' and 'values'.
  /// Make element name from baseName and tag name.
  let rec du2Xml (doc:X.XmlDocument) (du:obj) givenName :X.XmlElement = ...

  /// Build a document with du instance as its main element. 
  let buildDocForDU (rootDu) :X.XmlDocument =
    let doc = new X.XmlDocument()
    doc.AppendChild (du2Xml doc (rootDu :> obj) "") |> ignore
    doc

I am deliberately showing only the contract of each method the first time it appears, to clarify the result of each implementation decision. This also emphasizes my rationale for including type information on most parameters, even when that is not strictly required. I believe that it is easier for human readers if they can determine what the author intends simply by looking at a function's contract, without needing to examine the body that implements that contract.

Two additional details need explanation. First, "givenName" got added later in the design, once I got two-levels deep into the tree. Typically, an object is referenced by some (field or property) name in its parent; in XML it turned out to work most smoothly to keep that name with the data being referred to. We'll see this in use shortly.

Second detail, the need to cast "rootDu" to "obj". There is no base "DU" class (like there is an "Array" class for arrays), so in order to talk about instances of any DU, we need to be talking about "obj"s.

There is also something "absent" compared to a normal XML translator -- I didn't pass in a schema object. Here, the schema is the object's type, and will be obtained when needed by "ob.GetType()".

NOTE: I don't like having to put function declarations before their use. In C#, I would put the "most important" (and first needed by human reader) function "buildDocForDU" first, with "du2Xml" below it.