Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <039c01c4ad43$e45c6110$34000a0a@auburn>
From: "James Mitchell" <jmitchell@apache.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
References: <E1CFqAC-0005M2-00@smtp07.web.de>
Subject: Re: XML Im-/Ex-porter into Commons Sandbox
Date: Fri, 8 Oct 2004 10:34:17 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

I actually have no opinion about having multiple libraries that (almost)
server the same purpose, but with regards to the i18n project, I plan to add
the ability to tell it to use Digester (instead of the default) so you won't
actually need xmlio.


--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx

----- Original Message -----
From: "Daniel Florey" <daniel.florey@web.de>
To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>;
"'Martin Cooper'" <mfncooper@gmail.com>
Sent: Friday, October 08, 2004 4:31 AM
Subject: AW: XML Im-/Ex-porter into Commons Sandbox


Hi all,
I'll have a look at Digester again today and will compare the two approaches
finally for use in i18n.
As I know Oliver Zeigermann for a long time and he really is the master of
xml/sgml I everyone should give xmlio (good name indeed) a try.
Personally I like technologies that keep it very simple so that you
understand at the first sight what's going on without hiding too much
implicit logic.
As I stated earlier we have used Digester in a large project where a lot xml
parsing took place and we had some trouble with it (but that's some time
ago).
So I'd vote for putting the xmlio into the sandbox and let everybody have a
look at it. Even if it will never make it to commons components, it is worth
to have a look at its simplicity.
Regards,
Daniel


-----Urspr�ngliche Nachricht-----
Von: commons-dev-return-60296-daniel.florey=web.de@jakarta.apache.org
[mailto:commons-dev-return-60296-daniel.florey=web.de@jakarta.apache.org] Im
Auftrag von Martin Cooper
Gesendet: Donnerstag, 7. Oktober 2004 23:46
An: Jakarta Commons Developers List
Betreff: Re: XML Im-/Ex-porter into Commons Sandbox

On Thu, 7 Oct 2004 23:27:39 +0100, Stephen Colebourne
<scolebourne@btopenworld.com> 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.

In general, I agree with you. However, in this case, the reason for
bringing this component to the sandbox is because another component
that has only just arrived in the sandbox (i18n) wants to use it
instead of Digester. It seems that this XML component wasn't going to
be brought to Commons (at least for the moment) until there was
mention that i18n wanted to use it.

I'm not sure that I like the idea of new sandbox components bringing
along other components as baggage when there is already suitable
functionality available in Commons Proper. On the other hand, I would
not be opposed to bringing the XML component in _later_, and letting
it stand or fall on its own.

--
Martin Cooper


>
> 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" <grahamdavid1980@yahoo.com>
> > 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 <oliver.zeigermann@gmail.com> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org