[XML-SIG] Anything else to go in?

[Ken MacLeod]

Andrew Kuchling writes:
> Ken MacLeod writes:
> ><!-- Lightweight Distributed Objects XML Serialization DTD V0.1 -->
>  ...
> >     `ref' attribute of the `ref' element.  `dictionary', `list'
> >     and `value' elements support a `type' attribute to declare the
> >     type or class of the object.  `value' elements have an
> >     `encoding'
>
> This DTD looks simple to implement, requiring just a bunch of
> changes to the existing marshal.py.  However, I'd like to make the
> data structure -> LDO -> data structure transformation not lose any
> information, so I'd like to agree on certain coventional values for
> the 'type' attribute, such as integer, float, 'tuple' for the list
> element, etc.  Do you think it's possible to nail that down now, or
> is it premature?

Yes, I think now's a good time.

The DTD isn't set up to be formally specialized, but it was intended
to be informally specialized, which is what we'd be doing by nailing
down the types that Python would use for the transformation.  (Formal
specialization would use XML stuff like external DTDs and parameter
entities, similar to the DocBook SGML DTD.)

The general pattern I've had in mind for specialization is to start
off by just using the `type' attribute where appropriate to explicitly
declare what the element is supposed to be.  If simply giving a `type'
doesn't fit exactly, then a more complex ``encoding'' would be used,
where some rules are applied to translate the internal object type to
a suitable element with a certain `type' attribute.

As an FYI, the Python LDOConnection module should be able to use both
a Python-specialized marshaler to give a full-featured
Python-to-Python remote objects or procedure calls, as well as a
generic marshaler to give Python-to-other calls (as in other LDO
implementations).  In a sense, the binary implementation already has
this feature because you can swap-in(*) pickle.py for LDOBinary.py.
(* in theory -- the code to actually do it isn't there yet.)

The LDOBinary module was implemented as much by empirical testing as
by reading pickle.py and others, so I'm not sure how much I can help
with a truly lossless implementation :-).  I have a good feel for the
pattern I described above so I can help make sure what we come up with
is consistent with that.  Let me know what you'd like me to do.

 -- Ken