Thanks Craig, for your detailed response--I had to read it twice to fully absorb it! From the perspective of my concerns, you clearly found my cynicism unwarranted (to say the least). FWIW, my -1 is now a +1.
Also, it is evident that many of my remarks on BEA and its XMLBeans product were painfully classless and fourth-rate--for those who are or were affiliated with XMLBeans--please excuse my comments, they weren't justified given both what I knew and now know about the product. <red face/> With tail well between my legs, I'm now going to run back to the FOP project... Glen (who promises to submit a patch to Apache-XML Beans as penance ;) Forwarding, Craig McClanahan wrote: --------------------------------------------------- Glen (and others -- presumably someone will moderate this on to [EMAIL PROTECTED] for me), Thanks for the vote of confidence in my opinions :-). Although, I have to confess I'm by no means an expert in XML technologies, I'm fair-to-middlen at Java code, and I'm definitely a customer of XML technologies of various types (most heavily focused on reading configuration files in things like Tomcat and Struts, less so on rendering XML output). My comments will be mostly philosophical in nature, because I have not done any large scale investigation of XmlBeans as a technology; I've just played with the examples and thought about how it could be used. It's pretty intruiging, and I'll comment on that -- but I'd also like to throw a couple of comments in on the decision process of how we at Apache accept projects, and why we might want to or not want to accept it, or any other project. As such, I'm speaking in my "member of the Apache Software Foundation" and "member of the Jakarta PMC" hats. On Tue, 15 Jul 2003, Glen Mazza wrote: > Date: Tue, 15 Jul 2003 11:14:50 -0700 (PDT) > From: Glen Mazza <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [Fwd: Closure of XMLBeans vote] > > Berin, > > Sorry, I didn't know that committers--instead of only > the PMC--are able to vote on accepting XMLBeans. (I > have not subscribed to xml-apache-general until > today!) Let's extend voting a week or two longer, to > get votes from at least 30 or so committers. > > Offhand, I had some concerns about this technology > which I gave to my FOP team: > http://marc.theaimsgroup.com/?l=fop-dev&m=105784381703729&w=2. > Hence, my vote is -1. Quite frankly, I hope you have more backing up a -1 one vote than the three opinions you've expressed here: - "looks like a failed technology ..." - "BEA appears to want to avoid a block eye ..." - "XmlBeans are dead ..." without any corroborating evidence. It's fine to have opinions about whether a technology is successful or not, and I'm always amused when people try to ascribe single-minded motivations to large organizations (in my case, anyone who tells you that "Sun thinks this" or "Sun is doing that" doesn't understand that 40,000 employees don't have a single unified view on ANYTHING :-). But where's the beef? But, even if your presumptions about BEA's motivations were accurate (and I certainly don't get that impression from what I've seen so far), is that relevant to a decision on whether Apache should accept this technology? Personally, I don't think so -- what's important to me is that we be willing to host projects of "interesting" software that can attract a community of developers. Beyond interesting to developers, I also believe that Apache software should be interesting to users. (The thing that makes me the most proud about Struts, for example, is the user community, not the quality of the code, which is high, or even the really great group of committers that have come together to make it so.) The more important issues you raise, though, are really the two things that you mention in the middle paragraph: * The implied presumption that "XML and XSLT are too difficult to use and must be masked." (As a consumer of XML technologies, I must admit that I agree with this premise.) * The idea that different approaches to dealing with these technologies "may not be compatible with what XML-Apache is trying to accomplish." I'm kind of an odd duck -- I actually "get it" how SAX parsing works, and the kind of power that it can bring you, and enjoy writing code that works that way (along with JSP 1.x custom tags, that have the same sort of design, and even XSLT stylesheets, which I suspect tends to attract the same sort of mindset :-). But trying to explain the inverted control flow to most Java developers I'm familiar with quickly causes them to go cross-eyed, and they flee towards using DOM simply because they can understand it (no matter how clunky the W3C DOM API is to use). Therefore, one of the first things we did in Tomcat land was hide this complexity for the most important use case where we needed XML -- processing server.xml and web.xml files in Tomcat. The initial code was called XmlMapper, and it got morphed into the "digester" utility class in Struts 1.0 when I had the same need. Later, it became obvious that this need was general, and the code was abstracted out into commons-digester, which tends to be a popular download from Jakarta for simple use cases of converting XML data into Java objects. It was adopted by Tomcat in 4.1. Digester was also one of the inspirations for commons-betwixt, which does the opposite direction (Java objects -> XML data), again for relatively simple use cases. These libraries are popular, because they are easier to understand than the underlying XML APIs that Java exposes through JAXP (i.e. SAX and DOM). Indeed, the profusion of other innovation around basic XML processing APIs leads me to believe that it's not just the Java community that is looking for things a little easier to use :-). But using them comes with a penalty -- you have to hand create the corresponding bean classes. That can be a positive (you may not actually care about all the content in the document, and this is particularly true when reading configuration files). But it can be tedious -- and I've seen quite a few attempts at doing this kind of class generation dynamically. Obviously, someone else seems to think there is a real need here too. The second issue (conflict with other projects) speaks more to the Apache community's purposes of providing high quality software with active developer communities. At least over in Jakarta (which, after all, now hosts three high quality web application frameworks: Struts, Tapestry, and Turbine), we have not considered alternate solutions in the same problem space to be a fatal flaw. You'll see the same philosophy present in Jakarta Commons -- there isn't always "one right answer" to every single problem. Yes, groups are encouraged to work together instead of separately (and all three of these frameworks are already sharing fundamental pieces like the file upload package from Commons). In the case of XmlBeans, how you guys finally want to organize things (i.e. whether it gets absorbed into some existing xml.apache.org project that expands scope, or whether it stays separate) doesn't matter -- whether the technology itself is compelling and useful, AND can attract an Apache style developer community, is more important IMHO. As I said, though, I'm not all that familiar with the feelings toward community and internal competition on the XML side of the house. I probably should be, so this exercise is useful to me as a learning experience in addition to whatever advice I can offer on the particular subject at hand. > > I'm somewhat troubled by the voting options (listed > below): There should be an -1 option to refuse > XMLBeans into XML-Apache, period, without further > comment; similar to what already exists for +1. The > requirement to "address reservations [in order to > make XMLBeans acceptable for inclusion into XML-Apache]" in > order to vote a -1 is odd. One should not need to to > write a white paper on how to redeem XMLBeans in order > to (paradoxically) reject them! > > [ ] I agree with and support this proposal (+1) > [ ] Indifference (-1 < x < +1) > [ ] I object and suggest a way to address my > reservations (-1) > > -1 should be changed to: I reject adding the XMLBeans > project to XML-Apache. > > This will give a voice to those committers who > perceive that XML-Apache picking up XMLBeans would be > like General Motors deciding to resume the Edsel after > Ford determined it to be a failure. For those who > feel XMLBeans to be dead weight, a distraction that > XML-Apache doesn't need. > Again speaking from my experience in various Jakarta projects, we typically offer four choices on votes, rather than three: [ ] +1 -- I agree with the proposal and will support it (i.e. actively participate in making it happen). [ ] +0 -- I agree with the proposal, but can't really devote any reasons to supporting it. [ ] -0 -- I don't agree with the proposal, but I'm OK if the other voters want it. [ ] -1 -- I am against this proposal and here is why (and you must provide valid reasons). This seems to give Jakarta folks an appropriate range of expression to get their point across, and implicitly commits those who vote +1 to put their time where their keystrokes are, and really help. Per the voting guidelines, a -1 is a veto on "consensus only" votes (such as accepting a new committer), but it's just a "no" on majority rules votes (+0 and -0 are both considered abstentions when votes are counted). The requirement for *valid* reasons grew out of some painful experiences on a variety of lists, but is there mainly to avoid someone being able to throw a monkey wrench in the works solely to be a jerk, rather than having valid technical concerns. That doesn't mean there will never be an argument over whether a particular concern is "valid" or not (and there have been some doozies over the years :-), but it does behoove the person voting -1 to justify their position. Of course, that's the only way he or she would be able to influence the other voters anyway, but spurious -1 votes with no justification aren't counted. Different Jakarta subprojects might apply different standards to what "valid" means, but the ones I'm familiar with generally focus on technical issues, and facts, rather than suppositions and emotions. At least that is what we strive for :-). > But to satisfy the current requirement for voting -1, > here is one way to address my concerns: Can we get > Craig McClanahan's opinion of this technology--he > basically leads Jakarta Tomcat and Struts and is > quite "high up" at Sun. He has zero affiliation, > AFAIK, > with BEA. I have great respect for his integrity and > opinion--and if he endorses this technology, that's > good enough for me! OTOH, if he feels XMLBeans to be > "not the best", not something worth investing our time > on, I would continue to recommend XML-Apache passing > on this technology (i.e., -1). > OK, here's the deal. * No, I don't have any affiliation with BEA (so my boss at Sun can stop worrying :-), although I do talk to Cliff and several other of the folks that have been involved in XmlBeans on a variety of topics (such as the web app framework that BEA chose to utilize when the implemented page flow support into WebLogic Workshop this time around :-). * I don't know enough about XML processing to "endorse" this, or any other technology, as the "best". Indeed, you can count me as a skeptic on whether there IS such a thing as a best technology for mapping between XML data and an object oriented API that covers every use case. I'm not even sure I believe that it is technicallly feasible to cover 100% of the possible mappings. But a tool that meets a large percentage of the use cases can still be incredibly valuable. * I do find the XmlBeans approach to be interesting, and it appeals to my O-O mindset, coupled with a desire to make Java technologies in general easier for developers to use. It's pretty clear from the number of different approaches that are around (even just for Java bindings) that a lot of other people find the low level technologies too difficult to understand and use -- else why would we be seeing so many different approaches to fundamental things like a DOM API? * I don't doubt that there are alternative approaches already in existence, both at xml.apache.org and jakarta.apache.org. I would encourage you NOT to consider that an automatic reason to vote against. Diversity, cross-fertililzation of ideas, and (yes) even a degree of "competition" can lead to better projects. So can collaboration in an expanded project that might grow to a larger scope than it currently occupies, if that makes sense (that's for you guys to decide as part of the incubation process, if XmlBeans is accepted). * In earlier discussions (at least the ones I saw on the Jakarta General and community lists), there were concerns about licensing and the relative number of committers from BEA versus other organizations. Those sound like they are either resolved or will have the opportunity to be resolved in the incubator. * My only concern about XmlBeans, quite frankly, is one that you did not raise directly -- in the Java space there is a standard API for binding XML to Java objects (JAXB), and XmlBeans is not an implementation of that standard. That's not necessarily a fatal flaw (after all, my favorite webapp framework is not a standard either, although it is being impacted by the ones I deal with in my "day job" -- Servlet, JSP, JSTL, and JavaServer Faces), but it is a consideration to think about. Indeed, considering some of the loud voices at Apache, and their opinions on Java standards and the JCP, this might well be a positive :-). But it should be factored in to thinking about the effort that will be acquired to attract and maintain a developer community, and a user community, should XmlBeans be accepted. The XML community already has examples of both communities that implement standard APIs, and those who are innovating on their own. > Thanks, > Glen Mazza > FOP Team > Craig McClanahan __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
