Boost logo

Boost :

From: David Bergman (davidb_at_[hidden])
Date: 2002-11-19 13:16:42


Matthias,

(in the following, "object" denotes any value, primitive or not...)

It is obviously the case that there are object graphs in C++ that are
not homologous to any object graph in languages such as Java or Python.
Complexity is the price we C++ programmers pay for versatility and
power... I would actually argue that Java and, to some extent, Python
(although its dynamic character, with functions as even more first-class
residents than the functors of C++) are isomorphically embedded in C++
in that sense, i.e., every object graph in those two languages are quite
readily transformed to C++ graphs, with the corresponding semantics
attached.

But, one remark must be made:

The "Web Service" kind of data, transferred via XML, most probably
correspond to simple graphs in that they reside in the image of the
embedding isomorphism mentioned above. I.e., in those situations where
we have processing nodes in different language environments (or
cross-language) situations, there might be a greatest common divisor.
Even a divisor that small that good old VB will be a multiple ;-)

Regarding your comment about a direct "ad-hoc" embedding of the
marshalled binary data in a CDATA section, I totally agree, I just
wanted to expose that simplistic alternative.

The third alternative you mention, that of actually having a scheme
provided by the user (read "programmer") is quite versatile (read "in
the spirit of modern C++ development"). It might be quite a threshold
though for most users. I strongly feel that either alternative 1 (a
fixed XML Schema or DTD, considering or not considering poor non-C++
developers) or 2 (embedd the binary data in a CDATA section) must be
present in conjunction with such a versatile approach, as a default
setting.

There are a lot of powerful user-provided schema alternatives for XML
serailization in the soft world of Java, which I would be happy to
communicate with whomever taking on the task of "the third alternative".

A short note: I am a C++ developer, although I often wander in the
shadow of garbace collections...

Thanks for your comments,

David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Matthias Troyer
Sent: Tuesday, November 19, 2002 2:09 AM
To: Boost mailing list
Subject: Re: [boost] Serialization & XML (was Serialization Library
Review)

On Tuesday, November 19, 2002, at 06:22 AM, David Bergman wrote:

> Hi,
>
> This is a comment from the Java corner of the world: I have, as many
> other developers using Java, implemented serialization of objects onto
> XML. It is not that hard, although there might not exist (can anyone
> verify this?) a standardized (more or less...) "C++ Object XML
Format".
>
>
> There are two alternatives:
>
> 1. Use an intelligible XML Application (yes, that is what the XML
folks
> call the specific XML languages, such as XHTML...), giving not only
> platform independence (which I assume the serializer module already
> achieves...) but language independence, i.e., the object or value can
> be
> unmarshalled, or generated, by a Python program, much in the spirit of
> the good old XDR.

As nice as the idea is, there are C++ types that cannot be represented
in Java. Just consider templates or multiple inheritance (from two or
more base classes where neither can be represented as a Java interface)

> 2. Embed the binary output of the existing serializer in an XML
> element.
> This constrains the XML snippet to this particular serialization
> algorithm, including, at least initially, to the C++ language.

Sure, that is possible but probably not very suitable.

I guess another alternative is

3. allow the support of a user-defined schema for his classes with as
little constraints as possible. The questions now are: what are the
present constraints? I do not know.

Matthias

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk