Re: [boost] [Boost Review] Property Tree Library
Sorry, But I cant follow you in the thread so I have to put this at the top level of the thread. I am not at home right now.
I understood it perfectly well. However, you also stated that the parsers should come in at a later point. Thus my point still applies, if only for limited time. However, that time is crucial. If there is a Boost release (1.35) that includes the tree, but not the parser, people might get used to that "useless property_tree thing" and not care to look at its improved value in 1.36. Bad reputations tend to stick.
Poor points. Getting this library thing ready by version 1.35 or any other version is my last concern. I want it to be correct. Its not acceptable that that this fairly large library will not get the full review that is necessary for a boost library. The scope of this library is too diverse for it that too occur in only a 10 day review period. It is very, very common for libraries to need a second or even a third review. I think that this library falls in that category of libraries that will need multiple reviews.
Also, the way I understood your post, your objection to the parsers was that they are a completely separate thing from the tree and thus should not be reviewed together. I find this objection simply wrong. The parsers are a very important part of the property_tree library, and IMO it's just its inappropriate name that makes them seem misplaced.
As this seems to be opinion that you share with one or two others, please educate me. Why does the "property tree" require a parser. I just dont get it. How is the "property tree" container different from the vector and map containers, which almost certainly did not have parsers included along with them when they were added to the standard. What makes the "property tree" different from other containers that dont require parsers. I dont recall a single example of a container in C++ that had to have a parser. 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. This library will eventually get accepted, I'm fairly sure of that, possibly even portions of the library will be approved this time around. What is your rush to get this one through. Lets take our time and get it right.
Tom Brinkman wrote:
Sorry, But I cant follow you in the thread so I have to put this at the top level of the thread. I am not at home right now.
At least your still in the main thread :-) Why not use ThunderBird + gmane?
I understood it perfectly well. However, you also stated that the parsers should come in at a later point. Thus my point still applies, if only for limited time. However, that time is crucial. If there is a Boost release (1.35) that includes the tree, but not the parser, people might get used to that "useless property_tree thing" and not care to look at its improved value in 1.36. Bad reputations tend to stick.
Poor points. Getting this library thing ready by version 1.35 or any other version is my last concern. I want it to be correct.
Right.
Its not acceptable that that this fairly large library will not get the full review that is necessary for a boost library. The scope of this library is too diverse for it that too occur in only a 10 day review period.
You're allowed to think tbat. But the period itself is not the only and best meassure. I value the number of reviews and their depth more. Thats said, if the need arises, I hope we can extend the review period a few days.
It is very, very common for libraries to need a second or even a third review. I think that this library falls in that category of libraries that will need multiple reviews.
You're also allowed to think that.
Also, the way I understood your post, your objection to the parsers was that they are a completely separate thing from the tree and thus should not be reviewed together. I find this objection simply wrong. The parsers are a very important part of the property_tree library, and IMO it's just its inappropriate name that makes them seem misplaced.
As this seems to be opinion that you share with one or two others, please educate me. Why does the "property tree" require a parser. I just dont get it. How is the "property tree" container different from the vector and map containers, which almost certainly did not have parsers included along with them when they were added to the standard. What makes the "property tree" different from other containers that dont require parsers. I dont recall a single example of a container in C++ that had to have a parser.
To me you have completely misunderstood the library's purpose.
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.
For one, it is not a full xml-parser. I still hope that somebody will submit a mean SAX/DOM level 1,2,3 or whatever parser. There is barely no overlap with this library: the focus here is on simplicity and usability. The focus on an xml-library would be, well, full xml-support and lousy interfaces.
This library will eventually get accepted, I'm fairly sure of that, possibly even portions of the library will be approved this time around. What is your rush to get this one through. Lets take our time and get it right.
Let's see how the review unfolds. And let's hear more about what is wrong with it. -Thorsten
"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. -- Dave Abrahams Boost Consulting www.boost-consulting.com
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
Robert Ramey wrote:
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.
Not quite. The fourth, and very important, high-quality component that is missing is Boost.Unicode (or Boost.Recode or whatever). XML requires a lot of support for international character sets, at the very, very least UTF-8 and UTF-16, BE and LE. In practice, this means passing iterators that convert automatically to Spirit. Do we have such iterators? If I had that, I could start in the sandbox right now in my free time. Sebastian Redl
Sebastian Redl wrote:
Robert Ramey wrote:
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.
Not quite. The fourth, and very important, high-quality component that is missing is Boost.Unicode (or Boost.Recode or whatever). XML requires a lot of support for international character sets, at the very, very least UTF-8 and UTF-16, BE and LE. In practice, this means passing iterators that convert automatically to Spirit. Do we have such iterators?
I had to make my own such iterators in order to make xml_archives. These are described in the serialization library under the misc/dataflow iterators. I'm not sure what BE or LE refer to. But I did adress UTF-16 and UTF-8 was addressed with Ron Garcias UTF-8 codecvt facet. This is also documented in the misc section of the serializaiton library. A "complete unicode solution" has been discussed here in some length. The requirements kept growing until the job was undoable. Fortunately, I don't think a "complete unicode solution" is required to make a serviceable XML parser that we can build on.
If I had that, I could start in the sandbox right now in my free time.
great - when do you think you'll be done? Robert Ramey
Robert Ramey wrote:
I had to make my own such iterators in order to make xml_archives. These are described in the serialization library under the misc/dataflow iterators. I'm not sure what BE or LE refer to. But I did adress UTF-16 and UTF-8 was addressed with Ron Garcias UTF-8 codecvt facet. This is also documented in the misc section of the serializaiton library. A "complete unicode solution" has been discussed here in some length. The requirements kept growing until the job was undoable. Fortunately, I don't think a "complete unicode solution" is required to make a serviceable XML parser that we can build on.
BE and LE stand for Big Endian and Little Endian. The two UTF-16 variants are easy to cross-convert, but quite definitely different.
great - when do you think you'll be done?
Given the amount of free time I have ... but I'll start. I promise. Sebastian Redl
Not quite. The fourth, and very important, high-quality component that is missing is Boost.Unicode (or Boost.Recode or whatever). XML requires a lot of support for international character sets, at the very, very least UTF-8 and UTF-16, BE and LE. In practice, this means passing iterators that convert automatically to Spirit. Do we have such iterators? If I had that, I could start in the sandbox right now in my free time.
They're not full Boost components, but does boost/regex/pending/unicode_iterator.hpp do what you want (they are iterators that make one kind of Unicode sequence look like another). John.
Tom Brinkman wrote:
Poor points. Getting this library thing ready by version 1.35 or any other version is my last concern. I want it to be correct. Its not acceptable that that this fairly large library will not get the full review that is necessary for a boost library. The scope of this library is too diverse for it that too occur in only a 10 day review period. It is very, very common for libraries to need a second or even a third review. I think that this library falls in that category of libraries that will need multiple reviews.
So let's extend the review period if the library is too large to be reviewed within 10 days. But splitting it up makes little sense to me.
As this seems to be opinion that you share with one or two others, please educate me. Why does the "property tree" require a parser.
Because, as I said, it is inappropriately named. The "property tree" library submitted is not just the data structure. It is, to me, a framework to load, store, transport and save simple hierarchical configuration (or similar) data. As such it is useful to me. As such I'm already using it. As such it needs the parsers.
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.
You are wrong. I don't particularly care about the XML parser specifically. Replace it with a Java .properties parser, and I'll be just as happy. If ever I want an XML parser in Boost (and I want one, make no mistake), I don't want it some half-arsed thing that understands only a minor subset of XML. I want it a full-blown effort, providing generic pull- and push-parsers, a data structure complex enough that a DOM can be built on top (that could perhaps be a seperate effort, Boost.GenericTree), understanding namespaces and full DTD validation. Eventually, the library ought to evolve to have full Schema (and perhaps RelaxNG and Schematron) and XInclude support. In other words, an effort as complete as the parsers that come with Java. A parser on the level of PropertyTree's is so basic that I might as well replace those XML files with INFO or JSON.
This library will eventually get accepted, I'm fairly sure of that, possibly even portions of the library will be approved this time around. What is your rush to get this one through. Lets take our time and get it right.
I have no rush to get it through. If the whole library is ready by 1.36 or 1.37 or whatever, that's fine with me. But I want to get it through as a whole. Sebastian Redl
participants (6)
-
David Abrahams -
John Maddock -
Robert Ramey -
Sebastian Redl -
Thorsten Ottosen -
Tom Brinkman