At 10:01 PM 11/18/2002, Robert Ramey wrote:

>Is there a reason you sent this to me privately?
>> From: David Abrahams <[EMAIL PROTECTED]>
>
>>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.

Robert,

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.

--Beman


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

Reply via email to