Ah, now I understand your fears. Just another XML->Java mapper flying around ih the user list: <http://beck.sourceforge.net/>. However, xmlio is not a mapper to Java objects, you just receiver augmented SAX call backs. Enough talk, I will prepare something now...
Oliver On Fri, 8 Oct 2004 12:27:37 +0200, Oliver Zeigermann <[EMAIL PROTECTED]> wrote: > xmlio sounds like a nice name. I will prepare something to check in > for general inspection... > > Oliver > > > > > On Thu, 7 Oct 2004 23:27:39 +0100, Stephen Colebourne > <[EMAIL PROTECTED]> wrote: > > One of the key items in the commons charter is allowing different solutions > > to the same problem. So far, we have tended to avoid this (for example, I > > took a conflicting primitives design elsewhere) however we should not block > > this. > > > > What is being requested at this point is to factor out some code from > > another project (Slide) to commons. This is IMHO perfectly good and what > > commons is for. The code is going to the sandbox where we can all determine > > whether it is a good addition to the commons-proper fold. (eg. performance > > tests, code design, documentation). Who knows maybe the ideas will end up as > > digester 2! IMO thats what the sandbox is for. > > > > BTW, I don't disagree with the comments about bad dependency management > > below, I just disagree that that necessarily implies only ever supporting > > digester. > > > > Finally, the name ;-) > > xmlio (ie. xml io) > > sax > > saxio > > > > Typically, the commons project is named after the technology it works on. > > Without having seen the code its also difficult to judge what a good name > > would be ;-) I quite like xmlio myself. > > > > Stephen > > > > > > > > ----- Original Message ----- > > From: "David Graham" <[EMAIL PROTECTED]> > > > This will create bloat problems for clients that use Digester. For > > > example: Struts uses Digester for xml parsing. In the future Struts may > > > want to use the new i18n component. However, if i18n uses XML Im-Exporter > > > then Struts must drag that along too despite already having a perfectly > > > fine xml parser in its dependency list. > > > > > > Struts is just one example. It will be even worse for inter-commons > > > project dependencies. > > > > > > Bad dependency management has plagued commons components and it's just > > > recently started to get better. If all commons components use Digester > > > then we can avoid having to duplicate functionality and bloat > > > dependencies. > > > > > > I don't understand what's wrong with Digester that necessitates a new > > > parsing library. I've been able to write complex parsing rules in a > > > matter of minutes. > > > > > > David > > > > > > --- Oliver Zeigermann <[EMAIL PROTECTED]> wrote: > > > > > > > Folks, > > > > > > > > on the request of Daniel Florey I'd like to create at least one new > > > > sandbox component for a tool that allows easy import / export of XML > > > > into / from Java. It is used by Jakarta Slide and in the components > > > > Daniel introduced. > > > > > > > > I know this is a bit delicate as there already is Digester around in > > > > commons. However, the audience for my tool is different from > > > > Digester's. XML Im-/Exporter is geared towards high performance use > > > > for people who are very familiar with XML. It is just a little bit > > > > more than pure SAX. It also has a different philosohie than Digester. > > > > > > > > Having said that I hope not to cause any inconvenience with this... > > > > > > > > Preparing this now and cheers, > > > > --------------------------------------------------------------------- > > 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]
