Re: [i18n] Internationalization subproject sponsor?
> 6. Personally, I do not think the i18n issue is not only related to java > but also to all the *language*s. So, I suggested, "you do not have > to adhere to jakarta, IMHO". I do not think -> I do think :-) Sincerely, -- Tetsuya ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Internationalization subproject sponsor?
On Mon, 07 Jul 2003 08:14:06 -0400 (Subject: Re: [i18n] Internationalization subproject sponsor?) Robert Simpson <[EMAIL PROTECTED]> wrote: > I am surprised there isn't more interest in a common internationalization > framework within Jakarta. But then I have been assuming that there > are non-English-speaking "members" in Jakarta, not just "committers" > and other users of the code. When the proposal was first submitted > to the list, there seemed to be some initial interest - I even got > some suggestions for improving the code and incorporated those into > later revisions. But if there isn't much interest at this point, I > fear it will be difficult to get it into Jakarta at a later time. 1. There are many many non-English-speaking "members" as well as "committers" in jakarta. However, unfortunately non-Latin1-speaking "members" are a few. This means that they can not easily understand many hardships which people in multi-byte area *must* undergo. 2. Given that some of the members/committers in jakarta got aware the importance of the internationalization, I think they pretty do not know how to deal with it properly. (In short, they can not *test* easily in their environment) 3. In jakarta/apache, there are some projects using so called "Resource Bundle". (AFAIK: jakarta-jetspeed, maven and jakarta-struts, etc.) 4. Personally, I think it might be a nice idea to create i18n subproject and make *soft link* to each subprojects' directory/ resource bundles. In this way, we do not have to download all the subprojects' (e.g. apache-maven) modules and can contribute to the translation materials. (just download the i18n module and contribute to it) 5. The i18n subproject described above can also attract many contributors who are interested in the internationalization issues in general. The effort of the i18n proj can influence all the Apache related products. Maybe it can be a nice *community* which focuses on the internationalization issues related to the opensource communities. It would be very sad if the *know-hows*/*knowledge database* for the i18n/l10n issue will not be gathered in one appropriate place in apache/jakarta. The i18n subproject might be able to become a *symbol* of the ASF's i18n, and this gives a good *SIGN* that ASF is welcoming all sorts of the users' communities all over the world. I think it would be very nice if any committers in a specific subproject can easily ask to the community concerning with i18n issue, "I am lacking the know-hows on the i18n/l10n issue. Are there anyone who can support me/us here??". 6. Personally, I do not think the i18n issue is not only related to java but also to all the *language*s. So, I suggested, "you do not have to adhere to jakarta, IMHO". 6'. I think apache-httpd project had a great success in the i18n/l10n issue, so their knowledge might help you a lot. > BTW, thanks for sending the test "properties" file in Japanese. I > did incorporate that into the code, but just on my side so far. Okay. if you had any troubles with this, please let me know. Sincerely, -- Tetsuya ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XMLBeans performance and source code status [Re: Proposal: XMLBeans]
JSR-173 fits very well with the cursor-style strategy on the store. This is especially true of 173's XmlStreamReader interface - it can avoid object creation when iterating through XML. We've been closely reviewing the JSR and providing feedback to the EG. 173 hasn't gone final yet, but we'll be working on implementing the API both to read information out of the store and to connect to fast parsers. Difference between XmlCursor and XmlStreamReader itself is that XmlCursor is random-access-read-write while JSR-173 is read-only-forward-only. Sort of akin to the difference between DOM and SAX usage. So XmlCursor and XmlStreamReader are the same basic strategy, but applied to a different use case. -Original Message- From: Ted Leung [mailto:[EMAIL PROTECTED] Sent: Sunday, July 06, 2003 2:22 AM To: [EMAIL PROTECTED] Cc: Jakarta General List; [EMAIL PROTECTED] Subject: 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 > > > - 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: The vendors page
FWIW i think that the original arguments which lead to the creation of the vendors page are still relevant. it's very hard for any folks here to judge the merit (or otherwise) of companies providing support. on the other hand, there was a definite demand from users and vendors for a dating service. the original rule seemed to be a good one (a minimal test which some vendors have failed) as well having the merit of simplicity. on the other hand i do think that andrew's arguments have served a useful purpose in making us think harder about the purpose of that page. i also agree with alex in that probably the future direction is to something more apache-wide. on the other hand, i think that michael's answers have been reasonable and give him at least as much a reason as many of the existing vendors. unless i hear some good reasons not to, i'll probably commit something along those lines sometime soonish. i might also try to think of some ways to reorganize the page. - robert On Thursday, July 3, 2003, at 10:08 AM, Alex McLintock wrote: 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 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XMLBeans performance and source code status [Re: Proposal: XMLBeans]
Aleksander Slominski wrote: > did you consider "fail quickly" approach that is used in Java > collections (so for example Iterator can detect if it is used > from more > than one thread and fails if it happens)? the other > possibility would be > to allow making some objects (such as configuration) > immutable so can > be safely shared between multiple threads. Yes, we considered sync-free "fail fast" for working with immutable data. You are thinking along the same lines we have been as well. As far as we've been able to figure out (so far), sync-free mulithreaded access to immutable instances appears to require us to pay for all the work up-front instead of on-demand. (If, for example, you want to compute and remember the Calendar object the first time somebody has read a xs:dateTime, you need to write it somewhere, and as soon as you write anything without managing synchronization you end up with race conditions, especially given the out-of-order-write issue with the Java memory model) So sync-free- read-only-multithreading is not (yet) implemented. It is a potentially interesting area for experiments and measurement, but honestly probably a lot of work too. On the other hand, enabling sync-free single-threaded use seems to me like a clear thing to want to do, and probably significanly easier. > that sounds like very good strategy! however i winder what is really > current state. when i looked on source code and i could not see how > layering could work (or it working already?): what parts are API a > interfaces and how implementation is separated and can be > switched - is We've separated the public APIs in com.bea.xml.* from their implementations in the other packages. In particular, you can see our implementation of the cursor and the store are in com.bea.xbean.store.*, while users only ever hold on to the abstract interfaces com.bea.xml.XmlCursor or com.bea.xml.XmlObject. There is an XmlFactoryHook class that can be used to register interceptors for the (nonabstract) Factory methods, and this can be used to supply alternate implementations of XmlObject and XmlCursor. But this is a very coarse mechanism. As you observe, further factoring might make it eaiser to pick and choose alternate implementations for bits and pieces. So even though the public APIs are designed with layering in mind, being able to take out or plug in alternate implementations of different components is future work. It's probably appropriate to do as applications require it. (It should be doable, and if you have a project in mind we'll want to get you involved.) David Bau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Internationalization subproject sponsor?
Never mind I found the URL and the proposal. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Internationalization subproject sponsor?
Robert Simpson wrote: Andrew, In one sentence, it "intends" to provide a framework for internationalization of Java projects, within the Apache/Jakarta projects themselves and for users of the Apache/Jakarta code outside Apache. I am sorry for jumping in late to this thread. How does this proposal differ from the commons-resources project in the commons-sandbox that provides for internationalization? It can load resources from a properties/XML or database ? I had started out trying to see where I could make use of the Jakarta code, and eliminate duplication of effort on my part. But the one thing I ran into was most of the Jakarta subprojects do not provide for internationalization, which is a shame, because the Java SDK does quite a good job of providing support for that. That might actually be a good thing, since there currently is the opportunity to provide a framework for doing it in one place, rather than having each subproject do it differently. Robert Simpson "Andrew C. Oliver" wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vote for XMLBeans proposal
If Cliff is able to communicate BEA's preference, and the LGPL Piccolo issue is resolved, it seems like we're heading somewhere. Attracting new committers is easier when the project is already under incubation. Agreed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Internationalization subproject sponsor?
Tetsuya Kitahata, The "Incubation Process" document on the web site had indicated that the sponsor should come from the project that the "incubating" code would eventually be promoted into. Since trying to make use of Jakarta code is where I noticed the missing piece, that's the most obvious place it would go. I am surprised there isn't more interest in a common internationalization framework within Jakarta. But then I have been assuming that there are non-English-speaking "members" in Jakarta, not just "committers" and other users of the code. When the proposal was first submitted to the list, there seemed to be some initial interest - I even got some suggestions for improving the code and incorporated those into later revisions. But if there isn't much interest at this point, I fear it will be difficult to get it into Jakarta at a later time. I also fear that if I go back to simply continuing the development of the code myself, that eventually the need in Jakarta will be recognized, but I will be too far along at that point to convert everything to it. Or worse yet, the need will be recognized at different times within each Jakarta subproject, resulting in each subproject doing internationalization their own way. BTW, thanks for sending the test "properties" file in Japanese. I did incorporate that into the code, but just on my side so far. Robert Simpson Tetsuya Kitahata wrote: > Hello, Robert, > > Personally, I am interested in this project, but I am not a *member* > in ASF. (Just a *committer* in jakarta) > How about posting your message to > [EMAIL PROTECTED] > ?? > (subscribe: [EMAIL PROTECTED]) > Maybe, you can find the ASF *member* outside of jakarta. > > Here's a list of the number of *committer* and *member* in ASF umbrella > ( Originally created by Steven Noels) > -- > Amount of committers: 677 > > "Name","committers","members" > "ant","34","8" > "apr","42","32" > "avalon","80","15" > "cocoon","60","14" > "commons","10","10" > "db","35","9" > "embperl","13","6" > "httpd","145","111" > "incubator","26","12" > "jakarta","314","35" > "james","13","3" > "java","7","1" > "maven","25","4" > "mod_dtcl","9","4" > "modperl","18","7" > "tcl","9","4" > "ws","86","11" > "xml","259","28" > -- > > There are only 35 potential "Mentor"s (I mean, sponsors) in jakarta, as > you can see. If you are confident you can build a powerful community, > IMHO you do not have to stick to seek the Mentor in jakarta. > > I hope this mail might help you to some extent. > > Sincerely, > > -- Tetsuya ([EMAIL PROTECTED]) > > - > > On 3 Jul 2003 15:23:10 - > (Subject: [i18n] Internationalization subproject sponsor?) > Robert Simpson <[EMAIL PROTECTED]> wrote: > > > 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] > > - > Tetsuya Kitahata -- Terra-International, Inc. > E-mail: [EMAIL PROTECTED] : [EMAIL PROTECTED] > http://www.terra-intl.com/ > (Apache Jakarta Translation, Japanese) > http://jakarta.terra-intl.com/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --
Re: [i18n] Internationalization subproject sponsor?
Andrew, In one sentence, it "intends" to provide a framework for internationalization of Java projects, within the Apache/Jakarta projects themselves and for users of the Apache/Jakarta code outside Apache. I had started out trying to see where I could make use of the Jakarta code, and eliminate duplication of effort on my part. But the one thing I ran into was most of the Jakarta subprojects do not provide for internationalization, which is a shame, because the Java SDK does quite a good job of providing support for that. That might actually be a good thing, since there currently is the opportunity to provide a framework for doing it in one place, rather than having each subproject do it differently. Robert Simpson "Andrew C. Oliver" wrote: > >From the proposal I was not able to determine *what it intends to do*.. > Besides that, the criteria for helping is IMHO a bit discouraging. Granted > its hard to help if you've never been outside of Kansas, but maybe Dorothy > darn tootin cares about i18n and wants to make sure that toto can use her > application... Perhaps there is something left for her to do even if she > only speaks 'merican. > > -Andy > > On 7/5/03 12:16 AM, "Tetsuya Kitahata" <[EMAIL PROTECTED]> wrote: > > > Hello, Robert, > > > > > > Personally, I am interested in this project, but I am not a *member* > > in ASF. (Just a *committer* in jakarta) > > How about posting your message to > > [EMAIL PROTECTED] > > ?? > > (subscribe: [EMAIL PROTECTED]) > > Maybe, you can find the ASF *member* outside of jakarta. > > > > Here's a list of the number of *committer* and *member* in ASF umbrella > > ( Originally created by Steven Noels) > > -- > > > > Amount of committers: 677 > > > > "Name","committers","members" > > "ant","34","8" > > "apr","42","32" > > "avalon","80","15" > > "cocoon","60","14" > > "commons","10","10" > > "db","35","9" > > "embperl","13","6" > > "httpd","145","111" > > "incubator","26","12" > > "jakarta","314","35" > > "james","13","3" > > "java","7","1" > > "maven","25","4" > > "mod_dtcl","9","4" > > "modperl","18","7" > > "tcl","9","4" > > "ws","86","11" > > "xml","259","28" > > -- > > > > > > There are only 35 potential "Mentor"s (I mean, sponsors) in jakarta, as > > you can see. If you are confident you can build a powerful community, > > IMHO you do not have to stick to seek the Mentor in jakarta. > > > > I hope this mail might help you to some extent. > > > > Sincerely, > > > > -- Tetsuya ([EMAIL PROTECTED]) > > > > - > > > > On 3 Jul 2003 15:23:10 - > > (Subject: [i18n] Internationalization subproject sponsor?) > > Robert Simpson <[EMAIL PROTECTED]> wrote: > > > >> 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] > > > > - > > Tetsuya Kitahata -- Terra-International, Inc. > > E-mail: [EMAIL PROTECTED] : [EMAIL PROTECTED] > > http://www.terra-intl.com/ > > (Apache Jakarta Translation, Japanese) > > http://jakarta.terra-intl.com/ > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > Andrew C. Oliver > http://www.supe
Re: Vote for XMLBeans proposal
On 6/07/2003 16:56 Aleksander Slominski wrote: It seems that BEA folks are willing to solve all remaining problems and I think that it would be good if this project quickly gained more mementum and I am willing to help with it (even though I am not Apache XML commiter) This proposal is still lacking a better mix of BEA- and non-BEA committers, so it seems like your offer to help comes at a good time. ;-) FWIW: I would suggest XMLBeans to be incubated inside the XML project, although Jakarta would be equally fine as well. If Cliff is able to communicate BEA's preference, and the LGPL Piccolo issue is resolved, it seems like we're heading somewhere. Attracting new committers is easier when the project is already under incubation. -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Vote for XMLBeans proposal
Thanks to all of you for the many offers to help us get things started with XMLBeans. It sounds like it might be easier for everyone if we now pick one project that we believe would be the best fit for XMLBeans. From talking with a few committers, I think we are leaning towards the XML project, but I would like verify that with each of the others. I should be able to confirm this preference in the next 12-16 hours. Thanks again to everyone for being so willing to help make this work. BTW, I'll be at OSCON all week, if anyone would like to discuss any issues further. Cliff On Sunday, July 06, 2003 7:57 AM, Aleksander Slominski wrote: > Subject: Re: Vote for XMLBeans proposal > > > Berin Lautenbach wrote: > >> Ted Leung wrote: >> >>> Nicola Ken Barozzi wrote: >>> 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. >> >> >> The idea of moving XMLBeans to incubation under the XML project and >> with the assistance of Ted gets a +1 from me with some caveats : >> >> 1. Current XMLBeans committers need to be comfortable with this >> resting with the XML project in the first instance. Note that I would >> hope that the umbrella project could be changed prior to exit from >> incubation if the feeling from the committers was that it should be. >> >> If the initial preference is Jakarta then please indicate! I'm >> definitely not trying to push a line here, and it's easy to switch >> the vote over to the Jakarta PMC :>. >> >> 2. Committer issues that have previously been discussed will need to >> be worked through during incubation (although that's really what >> incubation is about :>). >> >> +/- from other XML PMC members welcome. >> >> Further discussion also welcome! > > hi, > > based on what I have seen when looking on XMLBeans source code and > (limited) design documentation I beleive that this project is very > interesting and useful for Web Services so I have CCed [EMAIL PROTECTED] > mailing list too. > > It seems that BEA folks are willing to solve all remaining problems > and I think that it would be good if this project quickly gained more > mementum and I am willing to help with it (even though I am not Apache > XML commiter) > > thanks, > > alek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
