David Abrahams wrote:
"Tom Brinkman" <reportbase@gmail.com> writes:
I suspect that those of you who want the parsers included with this library are just trying to sneek an XML parser through the review process without a full review. Please tell me that I'm wrong on this point.
I think it's best if we all operate as though our fellow Boosters are acting honorably and with the best intentions. I don't see how a suggestion that someone is trying to "sneek" a component through without full review can possibly be productive.
FWIW - When making a library beyond a certain size, its almost impossible to avoid "sneeking" (sic) some other new components along besides. Once something is needed, and you don't find it, you make your own. But given that you're already setup with testing, documentation, and yo want to make this new thing orthogonal to the central issue you're interested it, you end up with a new additional library. This happened to me and I ended up with extended_type_info, dataflow iterators, STRONG_TYPE and maybe others. These never got formally reviewed separately maybe they should have been or should be. But I do know that at least on occasion some of them have been used separately. So I could be considered of "sneeking"(sic) unreviewed components into boost. I will in fact confess that I sort of guilty of doing this intentionally. I packaged them as separate "libraries" but included them as part of the serialization libarry. There is no way I could find time to handle 3 or 4 more separate reviews. I was surprised that during the review no one really examined or criticised these components on their own. I don't have a real point here, I just wanted to add a little perspective on what really happens in cases like this. XML parser. - A ripe subject. I was never enthralled with XML and particularly for serialization. I felt I had to do this in order to get the serialization library accepted. And it did provide a torture test to double check that the archive concept was sufficiently defined to support even the most baroque formats. I believe that "requirement" that xml be supported was due to the misperception that an XML serialized data structure would be editable in some general way. Anyway, when I looked at XML, it was worse than I thought. It turns out that there are many, many ways that data could be written which would be compatible with XML. (I don't even think that name tags are strictly required). So I selected the simplest version that I thought would be acceptable and implemented using the spirit library. The spirit library included two XML grammars - I believed I used the simplest one. I'm pleased to say that, after some initial learning curve issues and after adding things for certain types of escapes - (not quite done here) this has worked out very well. The same grammar compiles with the most recent version of spirit as well as the older 1.6 version which is compatible with older compilers. Honestly, the advantages of maintainability, robustness, testing, quality, completeness, etc are such that I don't believe that any XML parsing writting "by hand" is going to be anything but inferior. Using spirit and Dan Nuffer's XML grammer is the only way to go. If this grammar needs to be refined/improved or made complete so be it. At least we would have a continually improving XML parsing solution that starts out high quality and improves from there. This would be much better than having a number of different XML parsers floating around. Given the avaliabilty of spirite, Dan Nuffer's XML grammar, and probably some sort of tree structure - adobe, multi-index, or roll your own from STL, I'm very surprised no one has submitted a DOM and/or SAX xml parser. It seems to me that this would be a straight forward composition of these three high quality components. It is surprising to me that given all the strong views expressed on the importance and utility of XML, and the fact that there are lots of ways to do it, and the fact that the serialization libray version doesn't support editing and doesn't permit the input to be re-ordered, that no one that I know of has submitted a variation/improvement on the xml_archive included. I suspect that the limitiations of XML for serialization become more apparent when one has more experience with the library and that the "extra" features aren't worth the effort required to make another archive. I'm also curious to know if anyone has had good success browsing the XML archive with any sort of tools. I think I tried the one that came with my VC 7.1 system but I wasn't left with a positive impression - I forget why now. Robert Ramey