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]
