From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-11-20 19:38:02
At 10:01 PM 11/18/2002, Robert Ramey wrote:
>Is there a reason you sent this to me privately?
>> From: David Abrahams <dave_at_[hidden]>
>>I believe your assessment that some
>>data structures can't be represented using XML is incorrect, and
>>that's easy to prove. A serialization library which makes generation
>>of XML output difficult is severely handicapped in the modern world.
>Well, I have conceded that it was preliminary. All I know about XML
>is from a small book containing a concise description of XML.
>My skeptism is based on the following thought experiment:
>Suppose on is given a list of polymorphic pointers, some of which
>correspond to bottom node of a diamond in heritance structure
>and some of which are repeated in the list and serialized
>some where else as well.
>a) How would such a thing be represented in XML?
>b) Could be loaded back to create an equivalent structure?
>c) Would it be useful for anything other than this serialization system?
>If someone can assure me that the answers to all three of the above
>is yes then it should be possible - otherwise not. Given that its
>"easy to prove" these questions should be easy to answer in
>a convincing way.
I think you may be missing several points with your thought experiment:
* The serialization library doesn't have to figure out how all C++ data
structures (such as in your thought experiment) would be represented in XML
or any other format. Instead, all that serialization has to supply is a
base class with the default hooks for prolog, epilog, separator, data, and
similar functions. It is up to the user to customize for a particular
format, beyond a few basic ones supplied by the implementation.
* Some approaches, including XML, allow a practically unlimited number of
different ways to represent the same data. The user rather than the
serialization library should choose the particular design.
* Some formats may not be able to support all C++ data structures, and that
is okay. For example, the comma separated value (CSV) format used by many
desktop tool programs won't extend much beyond arrays of simple structures.
That doesn't mean the format is useless and or that it shouldn't be
supported. It just means it isn't suitable for all tasks.
So what seems to me to be needed is a description of the concepts for input
and output format classes. As long at these are flexible, the users can
then work out many of the details for particular formats.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk