Anatoli Tubman wrote:

It absolutely certainly will be a new archive class. Sorry if it wasn't clear from the start.

I just think such an archive/serialization library is (a) useful enough to bea part of boost and (b) similar enough to the existing boost library to share the namespace with it.

I've got no problem with this.

I understand fully that this idea works only with tagged formats (not necessary just XML), that's why I'm saying that it should probably use a different syntax or maybe a sub-namespace under boost::serialization.

Within the boost::archive namespace I've got things like: basic_xml_iarchive xml_iarchive xml_wiarchive etc. I would think there is plenty of room for something like: basic_tagged_iarchive basic_tagged_xml_iarchive tagged_xml_iarchive tagged_xml_wiarchive etc.

I'm staying within program-structure-drives-data-format school of thought.

As long as you can stick with this, I think you can be successful. I briefly considered this approach. I imagined that upon archive creation the XML input could be parsed into a node tree. (insert plug for spirit here) The load_override function would be altered to search the correct part of the tree. So this would work and be pretty clean. I'm sure other approaches such as using SAX or DOM to parse the tree would work as well. Maybe there's another way I never thought of. The main reason I rejected the idea was that I didn't see it working with arbitrarily size streams. I envision serialization being used with stream much larger then available memory. This suggested to me an "on the fly" loader rather than a "pre-loaded". My implementation does require that tags remain in sequence and are all anticipated. Your proposal wouldn't have this restriction and might be preferred in certain applications. So I'm happy to encourage your efforts. I also hope that other users will be inspired to address more particular needs by creating their own archives class variations. In the long run, I'm trying to get out of the archive creation business in the same way I'm trying to get out of the class serialization business.

I don't precisely understand how going in the other direction is ever useful. Okay, given a DTD, you can generate a program that could read and write a bunch of data structures; but what will it *do* with them?

I can see the need for and utility of this. It's just that it's a whole different problem than what serialization addresses. Good Luck with this. Robert Ramey