Conclusion: Where to go from here

Conclusion: Where to go from here?
Neither XML-RPC nor xml_pickle are entirely satisfactory as means of representing the object instances of popular programming languages. But they both come pretty close. Let me suggest some approaches to patching up the short gap between these protocols and offer a general object serialization format.

"Fixing" xml_pickle is actually amazingly simple -- just add more types to the format. For example, since xml_pickle was first developed, the UnicodeType has been added to Python. Adding complete support for it took exactly four lines of new code (although this was simplified slightly by the fact that XML is natively Unicode). Or again, at the request of users, the numeric module's ArrayType was added with little more work. Even if a type is not present in Python, a custom class can be defined within xml_pickle to add the behavior of that type -- for example, REBOL's "e-mail address" type may be supported with a fragment like this:

<attr name="my_address" type="email" value="mertz@gnosis.cx" />

Once unpickled, either xml_pickle could just treat "email" as a synonym for "string," or we could implement an EmailAddress class with some useful behaviors. One such behavior, if we took the latter route would be pickling into the above xml_pickle fragment.

"Fixing" XML-RPC is more difficult. It would be easy to suggest simply adding a bunch of new data types, and from a purely technical point of view there would be no particular problem with this. But as a social matter, XML-RPC's success makes it difficult to introduce incompatible changes: A hypothetical "data-enhanced" XML-RPC would not play nice with all the existing implementations and installations. Actually, some implementors have felt sufficiently bothered by the lack of a "nil" type that they have added a nonstandard (or at best semi-standard) type to correspond to Java null, Python None, Perl undef, SQL NONE, and the like. But the addition of many more types that only some programming languages use is not going to fly.

One approach to enhancing XML-RPC as an object serializer is to coopt the <struct> element to do double duty. Everything that is incompletely typed by standard XML-RPC could be wrapped in a <struct> with a single <member>, where the <name> indicates the special type. While existing XML-RPC libraries do not do this, the XML-RPC protocol and DTD are so simple that adding this behavior is fairly trivial (but in most cases requires that the libraries be modified, not just wrapped).

For example, XML-RPC cannot natively describe the difference between Python lists and tuples. So the fragment in Listing 7 is incomplete as a description of a Python object.

<array>
  <data>
    <value>
      <double>11.2</double>
    </value>

    <value>
      <string>spam</string>
    </value>
  </data>
</array>

One could substitute the following representation, which is valid XML-RPC, and a suitable implementation could restore to a specific Python object:

<struct>

  <member>
    <name>NEWTYPE:tuple</name>
    <value>
      <array>
        <data>

          <value>
            <double>11.2</double>
          </value>
          <value>
            <string>spam</string>

          </value>
        </data>
      </array>
    </value>
  </member>
</struct>

A true <struct> can be represented in two (or more) ways. First, every <struct> can be wrapped in another <struct> (maybe with the <name> OLDTYPE:struct, or the like). For Python, this is probably best anyway, since dictionaries and object instances are both NEWTYPEs. Second, the namespace-like prefix NEWTYPE: can be reserved for this special usage (accidental collision seems unlikely).

By design, xml_pickle is more naturally extensible for representing new data types than is XML-RPC. Moreover, extensions to xml_pickle maintain good backward compatibility across versions. As its designer, I am happy with the flexibility I have included for xml_pickle. However, the fact is that XML-RPC is far more widely used and implemented. Fortunately, with only slight extra layering -- and without breaking the underlying DTD -- XML-RPC can also be adapted to represent arbitrary data types. The mechanism is somewhat less elegant, but XML-RPC is well thought out enough to allow compatibility with existing implementations after these adaptations.