Boost C++ Libraries: Ticket #7303: XML Serialization - Skip/Ignore unexpected data.

attachment set

anonymous — Thu, 30 Aug 2012 12:40:53 GMT

attachment → rapidxml_work.zip

attachment set

anonymous — Thu, 30 Aug 2012 12:43:27 GMT

attachment → svn.9.diff.zip

Diff against release branch

anonymous — Thu, 30 Aug 2012 13:05:25 GMT

attachment set

anonymous — Fri, 07 Sep 2012 10:03:59 GMT

attachment → rapidxml_work_16.zip

Updated patch

attachment set

anonymous — Fri, 07 Sep 2012 10:05:44 GMT

attachment → svn.16.diff.zip

Updated patch

anonymous — Fri, 07 Sep 2012 10:10:35 GMT

Update

I've fixed the two tests that were failing due to load_binary not being implemented.

I've still not looked into implementing polymorphic rapidxml archives.

attachment set

anonymous — Mon, 10 Sep 2012 09:11:15 GMT

attachment → rapidxml_work_17.zip

Source files (v17)

attachment set

anonymous — Mon, 10 Sep 2012 09:11:33 GMT

attachment → svn.17.diff.zip

Diff (v17)

attachment set

anonymous — Mon, 10 Sep 2012 09:11:50 GMT

attachment → rapidxml_work_18.zip

Source files (v18)

attachment set

anonymous — Mon, 10 Sep 2012 09:12:06 GMT

attachment → svn.18.diff.zip

Diff (v18)

anonymous — Mon, 10 Sep 2012 09:20:06 GMT

Update

Added polymorphic rapixml archive support (much easier than I anticipated)
Added support for flags

All tests now pass (gcc 4.6 and clang 3.0)

I think the next thing I'll do is go through the tests in detail, see what's covered, and what needs covering.

Robert Ramey — Mon, 10 Sep 2012 16:08:58 GMT

why have you not used the spirit parser as xml_iarchive does?

Seems to me that all this could have been achieved in a much simpler way with less code and less future maintenance requirement by updating the grammar on xml_iarchive. This would have guaranteed passing of all current tests out of the box.

Missing: a) Documentation/Explanation of what new features are offered and how they are used b) Tests of the new features

Robert Ramey

anonymous — Tue, 11 Sep 2012 11:40:25 GMT

Replying to ramey:

why have you not used the spirit parser as xml_iarchive does?

For the poor reason that I don't have any experience with spirit.

Seems to me that all this could have been achieved in a much simpler way with less code and less future maintenance requirement by updating the grammar on xml_iarchive.

So would I be right in thinking that you would extend the grammar to support element content, (either data or child elements), and extend basic_xml_grammar with a new method parse_content In this way I could skip to the end tag of the start tag just read if the name didn't match.

This would have guaranteed passing of all current tests out of the box.

A feature of xml_iarchive is that top level elements don't have their name checked. If there are multiple top level elements and I wish to skip any of them I will need to inspect their names. So changing the tests in the way that I have seems inevitable.

Missing: a) Documentation/Explanation of what new features are offered and how they are used b) Tests of the new features

Indeed. I am well aware that at this time it falls short of being a patch, which is why I didn't label it as such. I was really just after feedback, which you have provided, and for which I am grateful.

It would be extremely useful for me to be able to skip extra data in my applications' configuration file. It would allow some support for ver.8 applications opening ver.9 config files, though the limitations would be many: I could only ever add extra fields, I suspect I wouldn't be able to skip data if it was reference by other parts of the xml. But even with these limitations it would still be a useful feature to me. And since others have suggested it, I thought worth pursuing.

anonymous — Wed, 12 Sep 2012 08:27:09 GMT

Replying to anonymous:

Replying to ramey:

This would have guaranteed passing of all current tests out of the box.

A feature of xml_iarchive is that top level elements don't have their name checked. If there are multiple top level elements and I wish to skip any of them I will need to inspect their names. So changing the tests in the way that I have seems inevitable.

Actually, not being able to skip top level elements wouldn't be a significant limitation for me.

I'll give it some more thought. Thanks for your comments.

attachment set

anonymous — Tue, 18 Sep 2012 11:58:33 GMT

attachment → svn.23.diff.zip

Diff against release branch

attachment set

anonymous — Tue, 18 Sep 2012 11:58:58 GMT

attachment → work_23.zip

Source files

anonymous — Tue, 18 Sep 2012 12:15:39 GMT

I've done as you suggested. But in thinking about the documentation, I've started to wonder if this really is a good idea. I certainly don't think it should be documented as a feature because of the restrictions on it's use. At best it could be described in terms of some forgiveness/tolerance in the load.

Anyway, I'll leave it for your consideration.

Reference -> Special Considerations -> XML Archives

In addition, the XML format permits skipping unexpected content. XML archives will skip unexpected data but if that data is require by other parts of the archive the load will fail. In particular:

Objects at the top of the archive may not be skipped.
It is not possible to skip the first occurrence of a tracked object.

Ramki T — Mon, 28 Jan 2013 06:32:07 GMT

Hi,

I require forward compatibility in boost's xml serialization. So what is the status of this work? Please let me know.

Thanks & Regards, Ramki.

anonymous — Tue, 19 Feb 2013 12:51:23 GMT

Replying to Ramki T:

Hi,

I require forward compatibility in boost's xml serialization. So what is the status of this work? Please let me know.

You might be better off watching https://svn.boost.org/trac/boost/ticket/8088

In the end I converted my project to use boost::property_tree. Older versions of the application, written to use boost::serialization, couldn't load the boost::property_tree XML, but since they did't have future compatibility anyway, it wasn't much of a loss. However applications written to use boost::property_tree can easily load boost::serialization XML. And once you've made the jump, boost::property_tree provides better support for skipping extra data, and handling missing data. All-in-all it was a fairly painless conversion.

There are caveats:

If you need object tracking then boost::property_tree is of no use to you. But as I noted above I couldn't work out a way to modify boost::serialization to support future compatibility and object tracking (not fully at any rate). Perhaps others are more insightful.

The two libraries almost certainly have different memory/performance characteristics but again that didn't affect my project.

If you need UTF-8 support you'll need to imbue your input/output stream before calling boost::property_tree::read_xml/write_xml. (UTF-8 support isn't out-of-the-box.)

I hope that's of some use to you.