Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-11-18 07:50:53


> The problem here is that the way you want to serialize a
> std::pair<std::string,std::string> into XML might depend on the
> context. Sure, we can design an XML schema that is not context
> dependent, but most XML schemas are application specific and the way to
> serialize the data IS context sensitive.

The mapping can be context dependent if need be. It's not easy, but
it is very doable...
 
> For me XML I/O of class data using an application specific schema is a
> completely different application than just serializing a class object
> for persistent storage or transmission to another process. I don't
> think that any serialization library will be able to accomodate the
> variety of XML schemas that a user could come up with and still be able
> to factorize the output into context-insensitive serializations of all
> classes. See just my example above: the way I serialize the std::pair
> into XML is very application-specific and I might have other occurences
> of std::pair that should be serialized differently.

For XML, every different XML schema will probably amount to writing a
new input, output archive classes. I don't really have a problem
with that.

> Nevertheless, if you want XML, surely we can wrap the text archive
> between XML tags to get an XML file, but what is the point of that?

The point is to solve the N*M problem. I need to serialize my
'trade this stock' message (and a bunch of others) into FIXML
(an XML schema) and several other proprietary formats
including a database backend. The data in the message never
really changes much -- just the formats. I write the message
class load and save once and when someone comes up with a new
format it drops in quickly with no 'dangerous' changes to the
core of the system.

Anyway, my conclusion is there is nothing preventing using
serialization for XML other than the time and energy to do
it.

Jeff


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