[XML-SIG] Re: Marshalling to XML, again

[Ken MacLeod]

A.M. Kuchling <akuchlin@cnri.reston.va.us> writes:
> Here's another version of the xml.marshal module.  (That name will
> have to be changed now, though, since xml.marshal uses Python's
> original marshal to handle code objects.  Any suggestions?)

> For example, take the recursive list produced by this code:

> recursive_list = [None, 1, pow(3,65L), '<fake tag>', 1+5j]
> recursive_list.append( recursive_list )

> There's been some discussion of marshalling scripting language data
> types on the Casbah list and on the Perl-XML list recently;

Speaking from the Casbah project, we're just about to go 0.1 on our
Lightweight Distributed Objects.  0.1 won't have the XML serialization
implemented, but it is specified and will be plug-in compatible with
the current binary implementation.  The Python implementation is
browsable at:
  <http://www.ntlug.org/cgi-bin/cvsweb/lotos/python/>

The implementation for 0.1 includes the binary serialization, the
connection, and a remote proxy (method forwarder).  The last items to
clean up for 0.1 are the documentation and creating a coherent
release.

Initial notes on the XML serialization are in text format at:

  <http://www.bitsko.slc.ut.us/~ken/casbah/xml-serialization.txt>

The LDO equivalent serialization would look something like this:

    <list id=1>
      <null>
      <value>1</value>
      <value>10301051460877537453973547267843</value>
      <value>&lt;fake tag&gt;</value>
      <dict type="complex">
        <value>real</value><value>1.0</value>
        <value>imaginary</value><value>5.0</value>
      </dict>
      <ref id=1>
    <list>


In a followup message, Greg Stein <gstein@lyra.org> comments:
> Note: a Python client talking to a Python server could recognize
> that fact, marshal using the builtin, and then embed the data into a
> PCDATA element (or maybe encode using base64 for simplicity). It
> would fall back to the above marshalling for unknown targets.

We leaving a hook to support this in LDO, but assuming that the
built-in marshaling would completely replace the XML or binary
marshaling, rather than embedding it in XML.


This is more DO-SIG related, but from reading the above sample you can
probably guess an issue we're facing in the Python implementation: LDO
assumes that an implementation supports automatic or explicit coercion
from strings to numerics.

LDO supports numeric types (ints and floats), but doesn't require
them.  If the scenario was Python-to-Python, this wouldn't be a
problem because the calling Python code would encode using a numeric
type and the called Python code would decode the numeric type.  The
problem comes from command-line or TCL calling code talking to a
Python called code, or a Python calling code talking to a shell or TCL
called code -- numeric and string types aren't distinguished and
Python doesn't coerce between strings and numerics.

The solutions we've thought of so far are:

 1) require implementations to indicate numeric values (a real problem
for shells and TCL)

 2) require Python code to handle remote calls specially (a problem
specific to Python users that we had hoped to avoid)

 3) use CORBA IDLs (no worse than Java, C++, or CORBA)

 4) migrate Python to use non-math operators for string functions so
that math operators can signal coercion (an unlikely option)

(4) is the most elegant, but also the most difficult.  For now we're
starting with (2) and expecting (3) to be the ``final'' solution.

-- 
  Ken MacLeod
  ken@bitsko.slc.ut.us