Re: [vote] XMLBeans to enter XML incubation [was: Re: Vote for XMLBeansproposal in the XML Project (was RE: Vote for XMLBeans proposal)]
+1 I am planning to meet Cliff Schimdt in person at OSCon later this week. I will also be happy to be the official shepherd during incubation. Ted Berin Lautenbach wrote: +1. Subject to committer issues previously discussed being worked through in the incubator. Would it be worth each of the PMC reps putting this into the -dev lists? Am not sure if all committers are subscribed to general@ and it might make the logistics a bit easier? Am happy to help out on the logistics side, and I think Ted has also indicated he is happy to be the official shepherd. Cheers, Berin --- vote ballot -- Name: [ x ] I agree with and support this proposal (+1) [ ] Indifference (-1 x +1) [ ] I object and suggest a way to address my reservations (-1) -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
Nicola Ken Barozzi wrote: Greg Stein wrote, On 04/07/2003 1.24: On Thu, Jul 03, 2003 at 04:22:10PM -0400, Andrew C. Oliver wrote: To that extent, I'd say it is an XML project. There is another more simple rule. Who has shown that they want the project most? Apache.XML. Then let them have it. However, I think it is mostly up to the XMLBeans community to ask for one or the other. If that PMC says okay, then everything is fine. (and no... PMCs are not allowed to meet at sundown to duel for an arriving project :-) No? ;-P If XML.Apache is willing, as it seems, to cater for this project, I'll wait for a vote from them, an ACK from the Bea guys, and start preparing the hatcher :-) I'm happy to invest some time in helping XMLBean get throught the incubator -- speaking with my XML PMC and ASF member hat on. Ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XMLBeans performance and source code status [Re: Proposal: XMLBeans]
Eric, What's the relationship between XmlCursor and the JSR-173 Streaming API for XML? Ted Eric Vasilik wrote: When working with XMLBeans in a strongly typed way (with a Schema), individual objects are created for each piece of information, usually instances of simple and complex Schema types. However, you can also access and manipulate the XML in a typeless manor. What we've done with XMLBeans is provided access to the full XML Infoset via the XmlCursor interface. XmlCursor provides functionality very similar to the DOM, but takes a very different tact. Instead of creating an DOM Node for each element, attribute, text, etc, one may create a single XmlCursor and navigate that cursor about the XML instance, interrogating the XML: element/attr names, child/parent elements, text, comments, etc. Also, one may modify the XML by removing elements and attrs, inserting text, for example. All of this can be done by either not creating objects or reusing objects so that the number of objects needed to operate on the XML is constant, not on the order of the size of the XML like a DOM would require. The kind of interface allows an implementer of an in memory XML store more freedom to implement the internal structure which represents the XML in memory. One, for example, could simply store the XML as it was, for example, read in from disk and implement a cursor as an index into that string, parsing or modifying the parts of the string as necessary to satisfy the requests. We don't go to quite this extreme. In principle, we create one object for every leaf element or attribute and two objects for every interior element. All text for attribute values, comments, procinst's and text between element markup is stored in a single character array. We have found that creating fewer objects and batching text leads to loading the XML into memory faster as well as having a similar, if not slightly smaller, memory footprint when compared to the DOM. Also, working with cursors seems to be an easier programming model than the DOM as it does not have text nodes and is more intuitive. With respect to the synchronized access, the strongly typed schema XMLBeans objects cache values so that conversion to text does not occur until it is needed. Likewise, when modifications are made to the XML Infoset, the strongly typed data (ints, for example) are not parsed from the text until requested. In general the impact of synchronization is quite low because of the lazy approach we have taken along with the caching. As I read your question again, I realize that you may have interpreted synchronized to mean managing data among several threads. The synchronization described refers to the fact that one may manipulate the XML via the XmlCursor or the strongly typed XMLBean classes generated from the schema, each mechanism capable of seeing the changes from the other in a tightly integrated way. With respect to building XMLBeans, we plan to remove any dependency upon the jars you mentioned. Indeed, there exists very little dependence on these. Mostly just interfaces, not any classes needed for the implementation. - Eric Vasilik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution location]
I'd like to see this broken out of Maven / Centipede whatever, and put into libraries that can be used independent of the build tools. I also think that we need to plan for multiple repositories, whether they be ASF, ibiblio, what have you. There are two ideas going on in this thread. One is about the mechanism -- the repository, version management, dependency tracing, resource retreival etc. The other is about policy -- what kind of stuff can be in a particular repository. If the ASF ultimately decides to run its own repository with ASF policy that's fine. That shouldn't prevent the iBiblio repository (with a different policy) from continuing to exist. I'd hate to see us build mechanism that enforced policy. I'd like to lend a hand if this gets broken out into a separate project. Ted - Original Message - From: Jason van Zyl [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 11:40 AM Subject: Re: Clear the air Re: ATTN: Maven developers [was: primary distribution location] On Wed, 2003-02-05 at 14:35, Geir Magnusson Jr. wrote: On Wednesday, February 5, 2003, at 02:29 PM, Nick Chalko wrote: I hope to have a proposal started on the Wiki tonight (PST). The Maven repository has been an essential tool for me for me. The next step is to play nice with gump. Then do help with dependencies Also to make it easy for projects to brand themselves with version and dependency information. JJAR in commons sandbox had some of these ideas in there... But can you build this into maven rather than in parallel? The stuff in Maven can certainly be split out. As I said to Nick, it can already handle generation changes, evolution and the dependency mechanism in Maven already deals with non-JAR artifacts like WAR files, maven POMs, docs or whatever you want. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - 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
Let me second Andy's request. The proposal is much less interesting if what is developed is not usable by Maven -- Having a new project which competes with a piece of Maven will leave us with a bad solution for this problem space. Also, I think it's clear that the Maven developers have thought carefully about this problem, and I don't want to waste time reinventing the wheel or rediscovering the hard problems. Ted - Original Message - From: Andrew C. Oliver [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 1:08 PM Subject: Proposal Jason, Can you please add your name to this as a committer and/or a sponsoring member: http://nagoya.apache.org/wiki/apachewiki.cgi?RuperProposal Also other maven folks? I value your previous experience and existing source code. -Andy - 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: [RFC] Re: Helma XML-RPC @ Jakarta
Jason, If you want to get things ready that's okay by me, but if someone weighs in tomorrow, we'll have to wait. Ted - Original Message - From: Jason van Zyl [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, July 11, 2001 11:13 AM Subject: Re: [RFC] Re: Helma XML-RPC @ Jakarta On 7/11/01 12:29 PM, Ted Leung [EMAIL PROTECTED] wrote: The XML PMC has voted to accept Helma XML-RPC as an xml.apache.org project. Unless somone from xml.apache.org voices a serious objection by the end of Thursday, we'll start the wheels turning to create the project. Cool and the Gang :-) I will have everything ready for import by Friday, so I'll coordinate with Sam as it looks like everything is a go. I would like to use Anakia to generate the docs, is this acceptable? I already have the docs converted to Anakia so I'd like to use what I have. Ted - Original Message - From: Ted Leung [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 06, 2001 10:12 AM Subject: [RFC] Re: Helma XML-RPC @ Jakarta Does anyone else from xml.apache.org have any feedback on this proposal one way or the other? Ted - Original Message - From: Sam Ruby [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, July 05, 2001 6:09 PM Subject: Re: Helma XML-RPC @ Jakarta Jason van Zyl wrote: Fair enough, I will no longer argue the point. My main concern is that the project be granted full autonomy as a project initially as Hannes and the rest of the committers become accustomed to xml.apache.org than we can discuss the possible integration with Axis. Does this sound reasonable? +1 I'll even volunteer to set up the mailing lists, cvs trees, authorization, etc. And, of course, integrate it into Gump. ;-) - Sam Ruby - 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] -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons - 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: [RFC] Re: Helma XML-RPC @ Jakarta
The XML PMC has voted to accept Helma XML-RPC as an xml.apache.org project. Unless somone from xml.apache.org voices a serious objection by the end of Thursday, we'll start the wheels turning to create the project. Ted - Original Message - From: Ted Leung [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 06, 2001 10:12 AM Subject: [RFC] Re: Helma XML-RPC @ Jakarta Does anyone else from xml.apache.org have any feedback on this proposal one way or the other? Ted - Original Message - From: Sam Ruby [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, July 05, 2001 6:09 PM Subject: Re: Helma XML-RPC @ Jakarta Jason van Zyl wrote: Fair enough, I will no longer argue the point. My main concern is that the project be granted full autonomy as a project initially as Hannes and the rest of the committers become accustomed to xml.apache.org than we can discuss the possible integration with Axis. Does this sound reasonable? +1 I'll even volunteer to set up the mailing lists, cvs trees, authorization, etc. And, of course, integrate it into Gump. ;-) - Sam Ruby - 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: Helma XML-RPC @ Jakarta
One caveat. Let the XML PMC have it's vote on this. I'm sending the vote request in 2 minutes. Ted - Original Message - From: Jason van Zyl [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 06, 2001 6:54 AM Subject: Re: Helma XML-RPC @ Jakarta On 7/5/01 9:09 PM, Sam Ruby [EMAIL PROTECTED] wrote: Jason van Zyl wrote: Fair enough, I will no longer argue the point. My main concern is that the project be granted full autonomy as a project initially as Hannes and the rest of the committers become accustomed to xml.apache.org than we can discuss the possible integration with Axis. Does this sound reasonable? +1 I'll even volunteer to set up the mailing lists, cvs trees, authorization, etc. And, of course, integrate it into Gump. ;-) Cool, so can we coordinate next week sometime. Maybe toward the end of the week we can populate the repository? - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons - 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: Helma XML-RPC @ Jakarta
Hello all, It is not true that there is no interest in XML-RPC at xml.apache.org. I would be amenable to / in-favor of XML RPC being an independent project under xml.apache.org. I would prefer it if we could find a way to make this fit in with Axis, assuming that the respective committers can get along and make it work. The whole point of having a separate XML project is for XML related code-bases to go there. With a name like XML-RPC, it is hard to argue that XML-RPC is not an XML related project. Please don't try to circumvent the structure that the ASF has put in place. As someone pointed out, If we were talking about a C or C++ implementation of XML-RPC, then I don't think we would be arguing about where this particular code base belongs. Ted Leung Chair XML PMC - Original Message - From: Jason van Zyl [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 05, 2001 7:18 AM Subject: Re: Helma XML-RPC @ Jakarta On 7/5/01 7:55 AM, Pier P. Fumagalli [EMAIL PROTECTED] wrote: Hannes Wallnoefer at [EMAIL PROTECTED] wrote: To put it right upfront, I don't think XML-RPC is a natural fit for xml.apache.org, and I'd prefer to see it at Jakarta. Let me explain. Even though I see your point, I'd still prefer seeing it over in XML alongside with the other technologies doing the same exact thing... Jakarta has alrady a wide enough spectrum of problems covered (from build systems, to ioc frameworks). From what I can see, XML-RPC is based on XML (or a subset of it), is used to transmit objects and call methods over HTTP (same as SOAP), s, since it's an alternative to SOAP, it should go alongside with it. -1 for XML-RPC on Jakarta... So you would be amenable to the XML-RPC package being an independent project under the xml.apache.org banner? Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons - 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]
