RE: The vendors page
At 09:51 02/07/03 -0400, Howard M. Lewis Ship wrote: I'm tending towards the argument that if you can convince someone who has the right access to update the vendors.xml page, then you deserve to be on the list. Yep - so basically this should be decided on a subproject-level in Jakarta's case. I doubt *anyone* is able to support *all* Jakarta subprojects on a level that he/she serves his customers well. Suggestion: move this page away from the Jakarta main site, and stimulate subprojects to host their own vendor pages. /Steven -- Steven Noelshttp://outerthought.org/ I'm not sure of the point of a Vendors page. There are so many different types of vendors covering so many projects that a single page - or even a single XML is not necessarily the right thing. I started a database of companies who support open source software but I am not sure it is the right as it is. I think Apache has grown large enough to need a database of trainers, consultants, developers, vendors, and other support companies who will provide assistence with using Apache software. We had a small mailing list for discussing these sorts of commercial aspects to using Apache software but it never really got off the ground. Alex McLintock - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[i18n] Internationalization subproject sponsor?
To current members of the Jakarta project: Is there any current member of the Jakarta project who would be interested in sponsoring the entry of the Internationalization subproject into the incubator? The Internationalization subproject would be somewhat different than the other Jakarta projects in that there would be two types of contributors: 1. the (traditional) code contributors 2. the language translation contributors So far, the reponses I have received regarding people would would be interested in contributing have all been outside Jakarta - mostly language translators. Since the Internationalization subproject would most likely fit into the Jakarta project, it would help to have a sponsor from within Jakarta, per the Incubation Process documentation. The subproject proposal and initial code contribution can be found earlier in the Jakarta General mailing list, or here: http://www.itoolset.com/i18n/PROPOSAL.html Without a sponsor, I will probably move the code that was extracted in preparation for submission to Apache back into the iToolSet package hierarchy and let it pass as an Apache contribution until there is more interest in a common Internationalization architecture within Apache itself. Thanks in advance. Robert Simpson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
Craig R. McClanahan escribió: Snipping to an issue I have with one particular comment. I snip the whole thing, just to add. Read Craig's mail if you haven't :-) The Apache voting rules, where one -1 vetoes (and at the same time it is required to give substantial arguments about the veto) is, I think, precisely designed to enhance dialog and consensus over pure majority. I think this fact does a lot towards avoiding this kind of control traps and hidden agendas. This and the public discussions on the rationale of decisions. Regards -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
Simplistic standards like 51% of the ACTIVE committership from a different company might work for making simplistic decisions. They are not appropriate for a decision to accept a new project into Apache, which should be based on the quality of the proposed code and the proposed initial committers, not on the email addresses of the proposed initial committers. Maybe that¹s not a candidate for policy however it is required for MY vote. If your boss came and said Craig, if you don't vote X then you're fired and said this to a number of committers... While some might quit or whatever, I suspect the vote would be decided supposing they dominate the project. Furthermore, the interests of a set of employees of a company using a project for a particular purpose will tend to have homogenous interests. Thus will *tend* to vote similarly (if not the same way). It is my experience that developers who counter their employers interest do not stay employed for long. Lastly, developers who work together at work tend to communicate directly versus on community resources more frequently. In a NEW project it is my opinion that diversity should be settled up front so that no one company controls any new project. This is MY criteria for certain and required for my vote -- perhaps its not yours. -Andy Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
On 7/3/03 2:22 PM, Cliff Schmidt [EMAIL PROTECTED] wrote: As Santiago points out, the veto rule provides some protection over pure majority, but I don't think anyone here wants to rely on that. All I can tell you is that BEA is more concerned about establishing a long term relationship with Apache and other open source communities than controlling the future development of XMLBeans. From our perspective, we have much more to gain by proving ourselves as credible and positive contributors to open source, especially since we would like XMLBeans to be the first in a series of open source contributions. If the BEA committers attempt to make decisions against the wishes of the rest of the community and are viewed negatively for doing so, we have absolutely failed in what we set out to do. That is encouraging. That would be a nice development. Of course you understand that I don't want us to totally make an exception just because of this. At the moment, on the merits, the project has some difficulty. However using this motivation that you're expressing, I think this is a bridge that can be crossed. -andy See my response to Howard's questions for more on how the project differs technically from other open source projects. Cliff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Howard Lewis Ship PMC Nomination
Did anything every happen on this? I remember ACO sending out a message, but I don't know if it every made it to a vote. I'd really like to pursue this, because of my instatiable craving for power. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Issues with XMLBeans proposal
In summary the most serious issues to this proposal are: 1. diversity of committership. I'd personally like to see 51% of the ACTIVE committership from a different company. So long as a decision in one company can MAKE the vote, you don't have an Apache project, you have a corporate subproject at Apache. 2. Pick your project. I think it would have been a lot less confusing to mail the proposal to Jakarta or XML. Personally, if this is a Java only project, I think it should go to Jakarta. If it is a mult-platform C a/o C++ and Java, then it make sense for it to be part of XML. The proposers and sponsors should just decide and go in a single direction rather than kicking off a big debate. 3. Duplication of effort. The project encompasses schema validation which is done my XML parsers and it is Yet Another XML-Java binding API (there are some here and several elsewhere). From the standpoint of something I'd commit code to, this bores the crap out of me. From the standpoint of acceptability, its totally irrelevant. Choice is good, competition and cooperation exist not only in opensource but often in the same area of given projects. Thus if it can become an Apache community, then its irrelevant. 4. Machiavelli - I originally posted this to a private list because I didn¹t think it was good to say publicly, but rounding things out here might be good. Thus anointing BEA into the real open source and Apache world is a motivation. I don't think this project should be accepted without meeting the basic qualifications because of that, but maybe its a motivation to be a little more helpful than usual ;-). It might also round out the power structure at Apache a little if BEA began participating. Suggested courses of action: 1. Immediately begin recruiting other interested folks to round out the committership. This should not exit the incubator until 51% of regular voting committers are not from the same company. (meaning no show committers who never vote ;-) but round out the percentage) 2. Pick a project (XML or Jakarta) and say would you accept this given it is acceptable out of the incubator 3. Steven should begin suffering the incubator and moving the bureaucratic wheels. 4. set up the mail lists 5. Work on Gump integration and source structure to match other projects. 6. Project should be a subcontext of incubator for the moment. There are far more issues that must be worked out and confusion between a potential Apache project and an Apache project should be avoided. I still feel a little bit like this should start on sourceforge, round out the community issues, then move to incubator Thoughts? -Andy -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
Snipping to an issue I have with one particular comment. On Thu, 3 Jul 2003, Andrew C. Oliver wrote: In summary the most serious issues to this proposal are: 1. diversity of committership. I'd personally like to see 51% of the ACTIVE committership from a different company. So long as a decision in one company can MAKE the vote, you don't have an Apache project, you have a corporate subproject at Apache. Andy, I agree with you that diversity is important, but your proposed standard (more than half the committers from elsewhere) has some distrubing implications that are worth exploring. * There is an implied assumption that the proposed committers will behave the way that their employer wants, not the way that they want. Although it is too simplistic to say that this never happens (our individual actions are public record, so of course you take into consideration what your employer might think), developers that are solely corporate mouthpiece players should never have been elected as committers in the first place. * There is an implied assumption that all the committers from the same company will vote the same way. I can tell you from lots of experience over the last few years (some of it pretty painful and personal) that this is not likely to be a problem. If it is, then we screwed up on accepting the original committers in the first place. * There is an implied assumption that a person's employer (and therefore their corporate email address) should have anything to do with whether or not that person is individually a good choice for being an Apache committer. THAT should be the overriding concern -- after all, they will be able to stay a committer even if they move to a different job (within the same company or elsewhere). * What happens to your diversity statistics if a committer that was originally outside the originating company is then hired by that company to continue working on the project? One of the company's goals might well be to support open source by allowing that person to work on the project on company time; yet your proposed standard would view the change of employment as a negative and not a positive. Apache is about individuals, not about companies. Apache is about attracting high quality software projects, not about conspiracy theories (go back in the archives a couple years before you joined, and you'll see LOTS of discussion along these lines :-). Diversity is important -- a proposal that ONLY has committers from one company needs to be analyzied. But a proposal that includes a software contribution from a company, but WITHOUT any committers from that company willing to continue working on the software (the throw it over the wall scenario) would also be problematic. Simplistic standards like 51% of the ACTIVE committership from a different company might work for making simplistic decisions. They are not appropriate for a decision to accept a new project into Apache, which should be based on the quality of the proposed code and the proposed initial committers, not on the email addresses of the proposed initial committers. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Issues with XMLBeans proposal
I understand Andy's concern here, but I think Craig does a good job of pointing out the consequences of less participation by the core developers of a project, and the possibly invalid assumptions around that. As any of the committers can tell you, I wrestled with the list and really tried to limit the BEA involvement to a functional minimum. There are a few reasons why I ended up with 6 out of 9 being BEA folks: 1) I'm really hoping that other members of the Apache community will find this project interesting enough that we will end up with a couple experienced Apache people on our committer list, thereby reducing the BEA percentage. 2) The core XMLBeans developers (all BEA employees) are really excited about this stuff and want to do what ever they can to keep improving it. They are open to all kind of possibilities for refactoring, integration with other projects, and especially working with others on it...but they really all wanted to stay involved. It would probably be more efficient for BEA to have only a couple developers on the project, but the individuals wanted to be as involved as possible. 3) In the end, I had to go with the people I thought would have the most knowledge and experience with the code to lead by example. I am hoping that an active committer list will inspire community participation. I found three non-BEA people who I know will fill this role, plus the six BEA people. (I'll be responding to Andy's other points and Howard's email shortly.) Cliff On Thursday, July 03, 2003 10:01 AM, Craig R. McClanahan wrote: Snipping to an issue I have with one particular comment. On Thu, 3 Jul 2003, Andrew C. Oliver wrote: In summary the most serious issues to this proposal are: 1. diversity of committership. I'd personally like to see 51% of the ACTIVE committership from a different company. So long as a decision in one company can MAKE the vote, you don't have an Apache project, you have a corporate subproject at Apache. Andy, I agree with you that diversity is important, but your proposed standard (more than half the committers from elsewhere) has some distrubing implications that are worth exploring. * There is an implied assumption that the proposed committers will behave the way that their employer wants, not the way that they want. Although it is too simplistic to say that this never happens (our individual actions are public record, so of course you take into consideration what your employer might think), developers that are solely corporate mouthpiece players should never have been elected as committers in the first place. * There is an implied assumption that all the committers from the same company will vote the same way. I can tell you from lots of experience over the last few years (some of it pretty painful and personal) that this is not likely to be a problem. If it is, then we screwed up on accepting the original committers in the first place. * There is an implied assumption that a person's employer (and therefore their corporate email address) should have anything to do with whether or not that person is individually a good choice for being an Apache committer. THAT should be the overriding concern -- after all, they will be able to stay a committer even if they move to a different job (within the same company or elsewhere). * What happens to your diversity statistics if a committer that was originally outside the originating company is then hired by that company to continue working on the project? One of the company's goals might well be to support open source by allowing that person to work on the project on company time; yet your proposed standard would view the change of employment as a negative and not a positive. Apache is about individuals, not about companies. Apache is about attracting high quality software projects, not about conspiracy theories (go back in the archives a couple years before you joined, and you'll see LOTS of discussion along these lines :-). Diversity is important -- a proposal that ONLY has committers from one company needs to be analyzied. But a proposal that includes a software contribution from a company, but WITHOUT any committers from that company willing to continue working on the software (the throw it over the wall scenario) would also be problematic. Simplistic standards like 51% of the ACTIVE committership from a different company might work for making simplistic decisions. They are not appropriate for a decision to accept a new project into Apache, which should be based on the quality of the proposed code and the proposed initial committers, not on the email addresses of the proposed initial committers. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
So what in this ensures this will be a community-developed project and not just an Apache branded extension of BEA? I really would like to see you guys involved in Apache, but not in a way the compromises Apache. There is a challenge that limits the excitement of others in that there are so many other similar projects that do exactly the same thing. Perhaps it would benefit the effort if you explained why we needed another one. That has no bearing on its suitability but it might make people more interested who wouldn't be otherwise. Note that I didn't come up with the shouldn't be all from the same company requirement...that was noted long before my time.. -Andy On 7/3/03 1:27 PM, Cliff Schmidt [EMAIL PROTECTED] wrote: I understand Andy's concern here, but I think Craig does a good job of pointing out the consequences of less participation by the core developers of a project, and the possibly invalid assumptions around that. As any of the committers can tell you, I wrestled with the list and really tried to limit the BEA involvement to a functional minimum. There are a few reasons why I ended up with 6 out of 9 being BEA folks: 1) I'm really hoping that other members of the Apache community will find this project interesting enough that we will end up with a couple experienced Apache people on our committer list, thereby reducing the BEA percentage. 2) The core XMLBeans developers (all BEA employees) are really excited about this stuff and want to do what ever they can to keep improving it. They are open to all kind of possibilities for refactoring, integration with other projects, and especially working with others on it...but they really all wanted to stay involved. It would probably be more efficient for BEA to have only a couple developers on the project, but the individuals wanted to be as involved as possible. 3) In the end, I had to go with the people I thought would have the most knowledge and experience with the code to lead by example. I am hoping that an active committer list will inspire community participation. I found three non-BEA people who I know will fill this role, plus the six BEA people. (I'll be responding to Andy's other points and Howard's email shortly.) Cliff On Thursday, July 03, 2003 10:01 AM, Craig R. McClanahan wrote: Snipping to an issue I have with one particular comment. On Thu, 3 Jul 2003, Andrew C. Oliver wrote: In summary the most serious issues to this proposal are: 1. diversity of committership. I'd personally like to see 51% of the ACTIVE committership from a different company. So long as a decision in one company can MAKE the vote, you don't have an Apache project, you have a corporate subproject at Apache. Andy, I agree with you that diversity is important, but your proposed standard (more than half the committers from elsewhere) has some distrubing implications that are worth exploring. * There is an implied assumption that the proposed committers will behave the way that their employer wants, not the way that they want. Although it is too simplistic to say that this never happens (our individual actions are public record, so of course you take into consideration what your employer might think), developers that are solely corporate mouthpiece players should never have been elected as committers in the first place. * There is an implied assumption that all the committers from the same company will vote the same way. I can tell you from lots of experience over the last few years (some of it pretty painful and personal) that this is not likely to be a problem. If it is, then we screwed up on accepting the original committers in the first place. * There is an implied assumption that a person's employer (and therefore their corporate email address) should have anything to do with whether or not that person is individually a good choice for being an Apache committer. THAT should be the overriding concern -- after all, they will be able to stay a committer even if they move to a different job (within the same company or elsewhere). * What happens to your diversity statistics if a committer that was originally outside the originating company is then hired by that company to continue working on the project? One of the company's goals might well be to support open source by allowing that person to work on the project on company time; yet your proposed standard would view the change of employment as a negative and not a positive. Apache is about individuals, not about companies. Apache is about attracting high quality software projects, not about conspiracy theories (go back in the archives a couple years before you joined, and you'll see LOTS of discussion along these lines :-). Diversity is important -- a proposal that ONLY has committers from one company needs to be analyzied. But a proposal that
RE: Issues with XMLBeans proposal
On Thursday, July 03, 2003 11:01 AM, Andrew C. Oliver wrote: So what in this ensures this will be a community-developed project and not just an Apache branded extension of BEA? I really would like to see you guys involved in Apache, but not in a way the compromises Apache. There is a challenge that limits the excitement of others in that there are so many other similar projects that do exactly the same thing. Perhaps it would benefit the effort if you explained why we needed another one. That has no bearing on its suitability but it might make people more interested who wouldn't be otherwise. As Santiago points out, the veto rule provides some protection over pure majority, but I don't think anyone here wants to rely on that. All I can tell you is that BEA is more concerned about establishing a long term relationship with Apache and other open source communities than controlling the future development of XMLBeans. From our perspective, we have much more to gain by proving ourselves as credible and positive contributors to open source, especially since we would like XMLBeans to be the first in a series of open source contributions. If the BEA committers attempt to make decisions against the wishes of the rest of the community and are viewed negatively for doing so, we have absolutely failed in what we set out to do. See my response to Howard's questions for more on how the project differs technically from other open source projects. Cliff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
+1 On 7/3/03 2:26 PM, Neil Graham [EMAIL PROTECTED] wrote: Hi Cliff, I think the copy list of your note to Howard must have been a good bit narrower than the copy list of this response to Andy. :) Any chance you could enlighten those of us in this broader group who are interested as to the technical points on which XMLBeans differs from other technologies? Cheers! Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] |-+ | | Cliff Schmidt | | | [EMAIL PROTECTED] | | || | | 07/03/2003 02:22 | | | PM | | | Please respond to| | | general | | || |-+ - | | | | To: Jakarta General List [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] | | cc: | | Subject: RE: Issues with XMLBeans proposal | | | | | - | On Thursday, July 03, 2003 11:01 AM, Andrew C. Oliver wrote: So what in this ensures this will be a community-developed project and not just an Apache branded extension of BEA? I really would like to see you guys involved in Apache, but not in a way the compromises Apache. There is a challenge that limits the excitement of others in that there are so many other similar projects that do exactly the same thing. Perhaps it would benefit the effort if you explained why we needed another one. That has no bearing on its suitability but it might make people more interested who wouldn't be otherwise. As Santiago points out, the veto rule provides some protection over pure majority, but I don't think anyone here wants to rely on that. All I can tell you is that BEA is more concerned about establishing a long term relationship with Apache and other open source communities than controlling the future development of XMLBeans. From our perspective, we have much more to gain by proving ourselves as credible and positive contributors to open source, especially since we would like XMLBeans to be the first in a series of open source contributions. If the BEA committers attempt to make decisions against the wishes of the rest of the community and are viewed negatively for doing so, we have absolutely failed in what we set out to do. See my response to Howard's questions for more on how the project differs technically from other open source projects. Cliff - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Issues with XMLBeans proposal
Sorry about that -- looks like that mail didn't make it out of my outbox. I'll resend right now to all three lists. Cliff On Thursday, July 03, 2003 11:50 AM, Andrew C. Oliver wrote: +1 On 7/3/03 2:26 PM, Neil Graham [EMAIL PROTECTED] wrote: Hi Cliff, I think the copy list of your note to Howard must have been a good bit narrower than the copy list of this response to Andy. :) Any chance you could enlighten those of us in this broader group who are interested as to the technical points on which XMLBeans differs from other technologies? Cheers! Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] -+ | Cliff Schmidt | | [EMAIL PROTECTED] | || | 07/03/2003 02:22 | | PM | | Please respond to| | general | || -+ - | To: Jakarta General List [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] | cc: Subject: RE: Issues with XMLBeans proposal - | On Thursday, July 03, 2003 11:01 AM, Andrew C. Oliver wrote: So what in this ensures this will be a community-developed project and not just an Apache branded extension of BEA? I really would like to see you guys involved in Apache, but not in a way the compromises Apache. There is a challenge that limits the excitement of others in that there are so many other similar projects that do exactly the same thing. Perhaps it would benefit the effort if you explained why we needed another one. That has no bearing on its suitability but it might make people more interested who wouldn't be otherwise. As Santiago points out, the veto rule provides some protection over pure majority, but I don't think anyone here wants to rely on that. All I can tell you is that BEA is more concerned about establishing a long term relationship with Apache and other open source communities than controlling the future development of XMLBeans. From our perspective, we have much more to gain by proving ourselves as credible and positive contributors to open source, especially since we would like XMLBeans to be the first in a series of open source contributions. If the BEA committers attempt to make decisions against the wishes of the rest of the community and are viewed negatively for doing so, we have absolutely failed in what we set out to do. See my response to Howard's questions for more on how the project differs technically from other open source projects. Cliff - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Proposal: XMLBeans
(copying the other lists, by request) Thanks for all the good questions and advice, Howard. Please let me know if the following leaves you with other questions or concerns. On Wednesday, July 02, 2003 7:26 PM, Howard M. Lewis Ship wrote: See [http://workshop.bea.com/xmlbeans/quickStart.jsp BEA's quick start page] for more information. There's a commons module, Betwixt, that very much overlaps what you describe here. The main difference is the XML Schema support. However, there are areas of XMLBeans that overlap with other projects (especially commons modules like Betwixt). This is one of the reasons we are interested in Apache -- we would like to integrate/reuse as much as possible of other projects, especially if it makes the final product better. We also believe that the other projects could benefit from pieces of XMLBeans. What's compelling about XMLBeans compared to some of the other front runners, such as JDOM and XOM, Castor and JAXB? The main difference between XMLBeans and JDOM or XOM is that XMLBeans does not create objects for each XML information item. Instead, it provides cursor-based access to each item in the XML Infoset. It has an architecture where, if an actual object is needed for a node, it can be created on-demand. We found this provided great performance benefit. The biggest differences between XMLBeans and Castor or JAXB are: 1) the goal of 100% Schema support (currently supports everything in Schema other than redefine and substitution groups, and those features are nearly ready), and 2) the integrated and synchronized access of the underlying XML content with strongly typed Java classes. ''Meritocracy: '' We would very much like to see XMLBeans evolve under the meritocracy model that is used within Apache. The advice I got is still good ... get your meritocracy working RIGHT NOW. I personally found big benefits to reoganizing along these lines; it would have been worth the effort even if Tapestry hadn't made it all the way in. The meritocracy really works to get people motivated and contributing. I agree. We spent a lot of time thinking about the best community structure for XMLBeans and decided that the meritocracy by Apache was the model that we wanted to follow. We've made the first steps in this direction, but we are now trying to go all the way with it. Whether Apache is the right place for XMLBeans or not, we will be following the meritocracy model. In fact, we are looking at starting open source projects around several other technologies we've recently developed, and even though many of these won't be appropriate for Apache, we will still will be following a meritocracy model since we are also convinced that it really does work. ''Core Developers:'' In addition to key members of the XMLBeans development team, the initial committers include developers from outside BEA who have spent several months using XMLBeans to solve their particular development needs. Be prepared to document a bit more about outside developers' contributions. To be clear, the outside developers have only recently had the opportunity to submit patches, but they have been working closely with the BEA development team for six months by submitting bugs and feature requests based on the problems that they would run into while developing against XMLBeans within each of their applications. I've learned the hard way to get rid of all [L]GPL dependencies before you attempt to move to Jakarta. It's not even a question for us. We are in the process of dealing with this now. I just wanted to let you all know that we were handling it. Do you have a roadmap of where you would like this project to be in 6 months? A year? Two years? Yes - and I will post it shortly on the Wiki site. What licensing to you currently use? LGPL is a problem, BSD or ASL is the way to go. (Pardon me if this is on the pages you've linked to ... I haven't clicked through yet). We currently use an Apache-style license. See http://workshop.bea.com/xmlbeans/XsdUpload.jsp. '''(5) identify apache sponsoring individual ''' * Steven Noels ([EMAIL PROTECTED]) That's a good step! Yes - Steven has been incredibly helpful by allowing me to bounce ideas off him about how BEA can get involved with the open source community, and specifically if and how XMLBeans would be complement Apache. I'd be interested to know why you feel the project will benefit from hosting at Jakarta? My personal experience with Tapestry is that the move to Jakarta was good for exposure ... but Tapestry, regretably, did not have a major player (such as BEA) backing it. Eclipse, for example, self-hosts, yet is taken very seriously as an open source project. We are looking at open sourcing other BEA technologies, some of which would probably make the most sense in a self-hosted community, especially ones that we don't think Apache would be interested in. One reason we are
RE: Issues with XMLBeans proposal
Hi Cliff, I think the copy list of your note to Howard must have been a good bit narrower than the copy list of this response to Andy. :) Any chance you could enlighten those of us in this broader group who are interested as to the technical points on which XMLBeans differs from other technologies? Cheers! Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] |-+ | | Cliff Schmidt | | | [EMAIL PROTECTED] | | || | | 07/03/2003 02:22 | | | PM | | | Please respond to| | | general | | || |-+ -| | | | To: Jakarta General List [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] | | cc: | | Subject: RE: Issues with XMLBeans proposal | | | | | -| On Thursday, July 03, 2003 11:01 AM, Andrew C. Oliver wrote: So what in this ensures this will be a community-developed project and not just an Apache branded extension of BEA? I really would like to see you guys involved in Apache, but not in a way the compromises Apache. There is a challenge that limits the excitement of others in that there are so many other similar projects that do exactly the same thing. Perhaps it would benefit the effort if you explained why we needed another one. That has no bearing on its suitability but it might make people more interested who wouldn't be otherwise. As Santiago points out, the veto rule provides some protection over pure majority, but I don't think anyone here wants to rely on that. All I can tell you is that BEA is more concerned about establishing a long term relationship with Apache and other open source communities than controlling the future development of XMLBeans. From our perspective, we have much more to gain by proving ourselves as credible and positive contributors to open source, especially since we would like XMLBeans to be the first in a series of open source contributions. If the BEA committers attempt to make decisions against the wishes of the rest of the community and are viewed negatively for doing so, we have absolutely failed in what we set out to do. See my response to Howard's questions for more on how the project differs technically from other open source projects. Cliff - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Issues with XMLBeans proposal
Now to address, Andy's other issues (the first issue has spun off into a different thread)... On Thursday, July 03, 2003 8:57 AM, Andrew C. Oliver wrote: 2. Pick your project. I think it would have been a lot less confusing to mail the proposal to Jakarta or XML. Personally, if this is a Java only project, I think it should go to Jakarta. If it is a mult-platform C a/o C++ and Java, then it make sense for it to be part of XML. The proposers and sponsors should just decide and go in a single direction rather than kicking off a big debate. This is definitely a Java-only project right now. If that is a clear line of separation, I will stop posting to the XML list. The reason I posted to both lists was partly due to the fact that XMLBeans is much more XML-centric than Java centric (in terms of data modeling and the full fidelity availability of the XML Infoset); I really feel like this is one of those projects that could go either way. The other reason for posting to both lists is that three different Apache people (two of them ASF members) advised me to do so. I'm definitely interested in feedback as to whether to just limit the discussion to Jakarta right now. 3. Duplication of effort. The project encompasses schema validation which is done my XML parsers and it is Yet Another XML-Java binding API (there are some here and several elsewhere). From the standpoint of something I'd commit code to, this bores the crap out of me. From the standpoint of acceptability, its totally irrelevant. Choice is good, competition and cooperation exist not only in opensource but often in the same area of given projects. Thus if it can become an Apache community, then its irrelevant. I've tried to address some of the differences with XMLBeans and why I think it adds a lot more than currently existing projects (see my response to Howard -- http://archives.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]msgNo=15061). However, this might be a good time for David Bau, the architect behind XMLBeans, to jump in with his views. 4. Machiavelli - I originally posted this to a private list because I didn¹t think it was good to say publicly, but rounding things out here might be good. Thus anointing BEA into the real open source and Apache world is a motivation. I don't think this project should be accepted without meeting the basic qualifications because of that, but maybe its a motivation to be a little more helpful than usual ;-). It might also round out the power structure at Apache a little if BEA began participating. We would appreciate any help anyone has to offer, but I'm hoping we don't appear to need any special treatment. I've spent the last few months talking to everyone I can and reading everything I can about how to do this right. You and Howard have brought up some very reasonable points and I want to make sure I address them (either with further explanation or by making whatever changes to this proposal are necessary). Thanks, Cliff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
On 7/3/03 3:50 PM, Cliff Schmidt [EMAIL PROTECTED] wrote: On Thursday, July 03, 2003 8:57 AM, Andrew C. Oliver wrote: 2. Pick your project. I think it would have been a lot less confusing to mail the proposal to Jakarta or XML. Personally, if this is a Java only project, I think it should go to Jakarta. If it is a mult-platform C a/o C++ and Java, then it make sense for it to be part of XML. The proposers and sponsors should just decide and go in a single direction rather than kicking off a big debate. This is definitely a Java-only project right now. If that is a clear line of separation, I will stop posting to the XML list. The reason I posted to both lists was partly due to the fact that XMLBeans is much more XML-centric than Java centric (in terms of data modeling and the full fidelity availability of the XML Infoset); I really feel like this is one of those projects that could go either way. The other reason for posting to both lists is that three different Apache people (two of them ASF members) advised me to do so. I'm definitely interested in feedback as to whether to just limit the discussion to Jakarta right now. options: 1. Top level project - IMHO this isn't big enough and you don't have the open source experience or robust community to pull that off (not intended to be a criticism) 2. XML - I'm sure it would be fine. 3. Jakarta - IMHO this the best place for it. The division of XML vs Jakarta predates me for certain, but I think the main issues surrounding that are rusty. I've tried to address some of the differences with XMLBeans and why I think it adds a lot more than currently existing projects (see my response to Howard -- http://archives.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]msgNo=15061). However, this might be a good time for David Bau, the architect behind XMLBeans, to jump in with his views. Okay. It sounds like there are some issues which warrant this over others. I could see this being useful in things like web services as well... Limit object creation/serialization and yada yada yada... Though from reading the 10k foot view you could support JAXB if you wanted to. Just an element of curio for me...Offtopic...nevermind ;-) We would appreciate any help anyone has to offer, but I'm hoping we don't appear to need any special treatment. I've spent the last few months talking to everyone I can and reading everything I can about how to do this right. You and Howard have brought up some very reasonable points and I want to make sure I address them (either with further explanation or by making whatever changes to this proposal are necessary). Well the homogony is a big issue. Apache isn't a panacea, you'll have to work at it but I think you're sincere and motivated. Steven can help you through the gauntlet^M^M^M^M^M^M^Mincubator process and provided the committership had rounded out, and you integrated with Gump I'd vote in favor of Jakarta acceptance. (BTW acceptance to Jakarta is a majority of the Jakarta PMC vote)... It would be nice if other Jakarta PMC members sounded off a little so the incubator can hear. -Andy Thanks, Cliff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Proposal: XMLBeans
On Thursday, July 03, 2003 12:02 PM, Cliff Schmidt wrote: On Wednesday, July 02, 2003 7:26 PM, Howard M. Lewis Ship wrote: Do you have a roadmap of where you would like this project to be in 6 months? A year? Two years? Yes - and I will post it shortly on the Wiki site. I've just posted a description of what we have in mind at: http://nagoya.apache.org/wiki/apachewiki.cgi?XmlBeansRoadMap Cliff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
XML Beans details
On 7/3/03 4:22 PM Andrew C. Oliver [EMAIL PROTECTED] wrote: On 7/3/03 3:50 PM, Cliff Schmidt [EMAIL PROTECTED] wrote: this might be a good time for David Bau, the architect behind XMLBeans, to jump in with his views. Okay. It sounds like there are some issues which warrant this over others. I could see this being useful in things like web services as well... Limit object creation/serialization and yada yada yada... Though from reading the 10k foot view you could support JAXB if you wanted to. Just an element of Yeah, limiting object creation is one of the particular benefits to the approach. Also JAXB is of particular interest to us! We're particularly interested in JSR 222. I started writing up some details to the Q of what is XML Beans and how does it compare to X Y and Z? but it was getting long so I posted it on a wiki page http://nagoya.apache.org/wiki/apachewiki.cgi?XmlBeansExplanation David Bau XML Beans architect - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML Beans details
Hi David, Thanks for posting this detailed information! Although I'm afraid this might be far too esoteric for this broad audience, as someone who's been involved with a couple of schema validation implementations, I can't help but ask you about this particular bullet in the list: [[ It's robust enough that it is a self-hosted XML compiler. In particular, we don't have a hand-built schema parser. We use the automatically compiled XMLBean, compiled from schema-for-schema, to parse schema. I'm not aware of other binding tools that have enough depth of schema support to do that. ]] That's certainly not the road we went down in either Xerces-J 1 or 2. :) How does this approach handle things like the schema unique particle attribution or element declarations consistent constraints? Clearly you could parse schema documents simply using information from the schema-for-schemas, but using that alone, surely it's not possible to handle all conditions imposed on valid schemas by that spec. I'm raising this out of curiosity, not as any kind of objection. I would like to think that, if this code makes it into Apache--a point on which I'm agnostic for now--that synergies with related code like Xerces's schema support could be exploited wherever possible; but as Andy says in another note, competition is sometimes neither unavoidable nor even undesirable. :) Cheers, Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] |-+ | | David Bau | | | [EMAIL PROTECTED]| | | m | | || | | 07/03/2003 04:55 | | | PM | | | Please respond to| | | general | | || |-+ -| | | | To: Jakarta General List [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] | | cc: | | Subject: XML Beans details | | | | | -| On 7/3/03 4:22 PM Andrew C. Oliver [EMAIL PROTECTED] wrote: On 7/3/03 3:50 PM, Cliff Schmidt [EMAIL PROTECTED] wrote: this might be a good time for David Bau, the architect behind XMLBeans, to jump in with his views. Okay. It sounds like there are some issues which warrant this over others. I could see this being useful in things like web services as well... Limit object creation/serialization and yada yada yada... Though from reading the 10k foot view you could support JAXB if you wanted to. Just an element of Yeah, limiting object creation is one of the particular benefits to the approach. Also JAXB is of particular interest to us! We're particularly interested in JSR 222. I started writing up some details to the Q of what is XML Beans and how does it compare to X Y and Z? but it was getting long so I posted it on a wiki page http://nagoya.apache.org/wiki/apachewiki.cgi?XmlBeansExplanation David Bau XML Beans architect - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Howard Lewis Ship PMC Nomination
+1 On 7/3/03 4:59 PM, Howard M. Lewis Ship [EMAIL PROTECTED] wrote: Did anything every happen on this? I remember ACO sending out a message, but I don't know if it every made it to a vote. I'd really like to pursue this, because of my instatiable craving for power. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Howard Lewis Ship PMC Nomination
+1 Howard for King On Thu, 3 Jul 2003, Andrew C. Oliver wrote: +1 On 7/3/03 4:59 PM, Howard M. Lewis Ship [EMAIL PROTECTED] wrote: Did anything every happen on this? I remember ACO sending out a message, but I don't know if it every made it to a vote. I'd really like to pursue this, because of my instatiable craving for power. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Howard Lewis Ship PMC Nomination
Does it make sense that someone is nominating himself (or re-nominating himself) for membership? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Howard Lewis Ship PMC Nomination
Oooh ooh does that mean we all get to stab him? Sorry I'm from a violent culture...its our way... GET USED TO IT! ;-) http://linuxintegrators.com/hl30/blog/general/?permalink=And+that%27s+a+404+ on+the+Weapons+of+Mass+Destruction.html ;-) -andy On 7/3/03 6:03 PM, Henri Yandell [EMAIL PROTECTED] wrote: +1 Howard for King On Thu, 3 Jul 2003, Andrew C. Oliver wrote: +1 On 7/3/03 4:59 PM, Howard M. Lewis Ship [EMAIL PROTECTED] wrote: Did anything every happen on this? I remember ACO sending out a message, but I don't know if it every made it to a vote. I'd really like to pursue this, because of my instatiable craving for power. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Howard Lewis Ship PMC Nomination
On 7/3/03 6:23 PM, Jim Jagielski [EMAIL PROTECTED] wrote: Does it make sense that someone is nominating himself (or re-nominating himself) for membership? :-p We already voted him in...I nominated him a long while back...Just no one like...bothered to count the votes and do whatever was needed to instate him (like tell him how to subscribe) Now if he crowns himselfwe'll have to send troops and banish him to a small islandor come at him with knifes...depends on what kind of emperor he is -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XML Beans details
On Thursday, July 03, 2003 5:23 PM, Neil Graham [EMAIL PROTECTED] writes: How does this approach handle things like the schema unique particle attribution or element declarations consistent constraints? Clearly you could parse schema documents simply using information from the schema-for-schemas, but using that alone, surely it's not possible to handle all conditions imposed on valid schemas by that spec. Ah, Neil, you're a man in the trenches with Schema along with me! My apologies Neil, Just after hitting send I realized I think I answered a different question than the one that was asked. Let me try again. We have three layers the compiler handles. Basically the compiler's job is to go from (1) - (2) - (3). (1) Schema syntax (2) Schema type system in-memory (3) Schema metadata binary persistence format Layer (1) is handled by schema-for-schema as described in the previous mail. Layer (2) is where we do type resolution and verify all the semantic rules of schema that are not imposed by s4s for example particle valid (restriction) and element consistency and actually many many many other rules. I think layer (2) is the answer to your question. Layer (2) catches the valid-schema errors that are not syntactic-validation issues. Building layer (2) is the core of the compiler. Once we pass layer (2) then we have a fully valid schema type system and can persist it as layer (3). Layer (3) can be loaded directly at runtime for high-speed schema validation. [basically it reconstructs (2) on-demand.] Or at runtime if you choose to build the schema types via layer (1) and (2) you can do that too. David Bau XMLBeans Architect - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
From: Andrew C. Oliver [EMAIL PROTECTED] On 7/3/03 7:24 PM, Greg Stein [EMAIL PROTECTED] wrote: ... okay, then everything is fine. (and no... PMCs are not allowed to meet at sundown to duel for an arriving project :-) Everyone always takes all the fun out of my life :. Out of curiosity - does it have to be decided now? If there is a general feeling from the two PMCs that they would be comfortable, then maybe we both sponsor into the incubator and give the committers time to migrate everything to Apache. Presumably in that time they are also getting used to Apache and can develop an understanding of where they feel their project fits best. Cheers, Berin This message was sent through MyMail http://www.mymail.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
