[XML-SIG] WDDX for Python

[Paul Prescod]

Simeon Simeonov wrote:
> 
> Think of WDDX as the epitome of the 80/20 rule. 

Maybe 60/40? :)

> When you want to reach such a wide audience you have to make concessions. In
> particular, we had to decide that we couldn't exchange objects because some
> of the target languages have no notion of such.

Objects??? Are we integrating with Perl 4.0?

Okay, what if we just add an *optional* attribute called "type" to
structs. People could ignore it if they want to but as a Python programmer
I wouldn't feel like I was throwing away Really Important Information. 

Also, what if we added an optional "id" attribute and a <REFERENCE>
type...(maybe I can wait on the reference type for WDDX 2, but I'd rather
not)

> I would disagree with you here... How can a Python app exchange data with an
> ecommerce app written in ColdFusion? Or a book browser that's written in
> Perl? Or with Microsoft Word? How can it send a recordset and a three
> dimensional array to a web browser where these data can be used to build
> cool DHTML UI?

If I had to send a 3D array of integers to Perl, I would send a bunch of
lines like this:

23 43 564 234
40 203 03 203 
23 430 23 10

It is presumably two lines of Perl code to split that up and convert it to
integers. To me, the big win comes when I can send an OBJECT to Perl
without dumbing it down into basic types. In fact, I think that the only
features that I need to do this AS WELL AS the native Python tool called
"pickle" is the "type" attribute and ID/IDREF. If I could just not throw
away types then I could at least handle simple, non-recursive data
structures okay (i.e. ID/IDREF can maybe wait).

> And, yes, it is not easy to wrap objects around the data returned by a
> deserializer. Probably the easiest way to do this is to build an object
> factory for particular types of WDDX packets and apply it on the result of
> the deserialization. Whether this will be worth doing depends on your
> application.

Except that packet types aren't self-labelling either. They do have a
place for meta-data, however. If we could provide a place in structs for
arbitrary metadata, we would be almost home.

BTW, wouldn't the packet metadata be more useful if there was some
attribute that let me say what kind of metadata it was, like HTML META
tags?

> Bottom line: WDDX is not a solution for python-python object serialization.
> It can, however, open python apps up and let them communicate with a _huge_
> number of other applications.

Sure, but we're so close to making it useful for Python->Python and (more
interesting) Python->arbitrary OO language (including Perl 5) object
exchange. I think that all we need is one attribute.

The attribute should contain a URI (URIs are language independent) and
each deserializer could have a mapping from URIs to class constructors.
Languages that don't have a notion of class would ignore the URI. URIs are
verbose but of course they compress beautifully.

 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

"Sports utility vehicles are gated communities on wheels" - Anon