You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Oliver Zeigermann <ol...@gmail.com> on 2004/10/07 21:30:03 UTC
XML Im-/Ex-porter into Commons Sandbox
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,
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: XML Im-/Ex-porter into Commons Sandbox
Posted by Oliver Zeigermann <ol...@gmail.com>.
On Fri, 8 Oct 2004 10:31:44 +0200, Daniel Florey <da...@web.de> wrote:
> 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.
I am certainly far from being a master in anything, but thanks for the
flattery ;)
> 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.
That's what it was designed for.
> 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.
Agreed. Let me put it there and if it turns out to be crap or
unusable, we can certainly abondon it.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: XML Im-/Ex-porter into Commons Sandbox
Posted by Dion Gillard <di...@gmail.com>.
If you're looking for something simple, you may want to check out
http://xstream.codehaus.org/ as well.
On Mon, 11 Oct 2004 08:35:01 +0200, Oliver Zeigermann
<ol...@gmail.com> wrote:
> Hi Simon,
>
> I really appreciate your input, thanks again :)
>
> On Mon, 11 Oct 2004 19:15:11 +1300, Simon Kitching
> <si...@ecnetwork.co.nz> wrote:
> >
> > >
> > > As I already tried to explain. Both are soooooo different. No need for
> > > any worries...
> > > They even serve a different audience I guess. Digester is good for
> > > people who do not want to see any XML stuff and what Java objects,
> > > with xmlio you are closer to the guts of SAX and XML.
> >
> > I don't actually see that they are that different.
> >
> > You can use Digester in a manner very similar to the way xmlio is used.
> > This is not the way Digester is "marketed" in its examples but it is
> > still quite valid:
> >
> > class Foo {
> >
> > private class HandleWidget extends Rule {
> > public void begin(...) {
> > // code to do stuff when a widget tag is found
> > }
> > }
> > ...
> >
> > digester.addRule("/root/widget", new HandleWidget());
> > digester.addRule("/root/gadget", new HandleGadget());
> >
> > xmlReader.setContentHandler(digester);
> > xmlReader.parse(input);
> > }
> >
> > Here's the xmlio equivalent (I think...)
> >
> > class Foo {
> > private class MySimpleImportHandler implements SimpleImportHandler {
> > public void StartElement(...) {
> > if (path.equals("/root/widget) {
> > // code to do stuff when a widget tag is found
> > }
> > else if (path.equals("/root/gadget") {
> > // code to do stuff when a gadget tag is found
> > }
> > }
> >
> > simpleImporter.addSimpleImportHandler(new MySimpleImportHandler());
> > saxParser.setContentHandler(simpleImporter);
> > saxParser.parse(input);
> > }
>
> Agreed.
>
> > In other words, Digester *can* be used as a "light wrapper around SAX".
> > The begin/body/end methods of a custom Rule class are basically the SAX
> > callbacks; when using Digester in this style, Digester is really just an
> > "event dispatcher" routing each sax event from a single ContentHandler
> > class to zero or more relevant rule classes to avoid having big
> > cascading if/then statements in the ContentHandler class.
> >
> > It wouldn't take too much work to provide xmlio's convenient feature of
> > passing the attributes into the body/end methods as well as the begin
> > method. It doesn't need to provide xmlio's Path functionality because
> > the "event dispatching" mostly removes the need for that.
> >
> > The problem at the moment is it brings with it so many inter and intra
> > library dependencies that there isn't a light *distributable package*
> > containing just the core Digester classes.
> >
> > I'm certainly not trying to criticise xmlio; I'm just concerned that
> > multiple projects will both dilute the available developer pool and
> > confuse potential users. And all that extra work - unit tests, project
> > website, etc! If the projects are truly providing different
> > functionality, well there's no issue. But as I understand xmlio now, I
> > think that exactly the same goal can be achieved with almost exactly the
> > same amount of custom code with both libs.
> >
> > Oliver: do you feel that the fact that Digester does "sax event
> > dispatching" while xmlio doesn't really make the lib feel different to
> > you? (honest question, it is a slightly different paradigm, like OO vs
> > procedural). Is there something else that makes you feel Digester is
> > fundamentally different from xmlio?
>
> Simplicity and obviousness, having all parts of the code and the data
> that are associated at one spot. Next is performance and actual
> complexity of code. Next is amount of created objects.
>
> Still, these are just considerations that come from my personal taste.
> When rules become a bit more complicated, it might become pretty hard
> to understand what is going on in the guts. A large block of if /
> else statements might not be what people - including myself - would
> call exactly elegant, but it is obvious with no secrets.
>
> Oliver
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
http://www.multitask.com.au/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: XML Im-/Ex-porter into Commons Sandbox
Posted by Oliver Zeigermann <ol...@gmail.com>.
Hi Simon,
I really appreciate your input, thanks again :)
On Mon, 11 Oct 2004 19:15:11 +1300, Simon Kitching
<si...@ecnetwork.co.nz> wrote:
>
> >
> > As I already tried to explain. Both are soooooo different. No need for
> > any worries...
> > They even serve a different audience I guess. Digester is good for
> > people who do not want to see any XML stuff and what Java objects,
> > with xmlio you are closer to the guts of SAX and XML.
>
> I don't actually see that they are that different.
>
> You can use Digester in a manner very similar to the way xmlio is used.
> This is not the way Digester is "marketed" in its examples but it is
> still quite valid:
>
> class Foo {
>
> private class HandleWidget extends Rule {
> public void begin(...) {
> // code to do stuff when a widget tag is found
> }
> }
> ...
>
> digester.addRule("/root/widget", new HandleWidget());
> digester.addRule("/root/gadget", new HandleGadget());
>
> xmlReader.setContentHandler(digester);
> xmlReader.parse(input);
> }
>
> Here's the xmlio equivalent (I think...)
>
> class Foo {
> private class MySimpleImportHandler implements SimpleImportHandler {
> public void StartElement(...) {
> if (path.equals("/root/widget) {
> // code to do stuff when a widget tag is found
> }
> else if (path.equals("/root/gadget") {
> // code to do stuff when a gadget tag is found
> }
> }
>
> simpleImporter.addSimpleImportHandler(new MySimpleImportHandler());
> saxParser.setContentHandler(simpleImporter);
> saxParser.parse(input);
> }
Agreed.
> In other words, Digester *can* be used as a "light wrapper around SAX".
> The begin/body/end methods of a custom Rule class are basically the SAX
> callbacks; when using Digester in this style, Digester is really just an
> "event dispatcher" routing each sax event from a single ContentHandler
> class to zero or more relevant rule classes to avoid having big
> cascading if/then statements in the ContentHandler class.
>
> It wouldn't take too much work to provide xmlio's convenient feature of
> passing the attributes into the body/end methods as well as the begin
> method. It doesn't need to provide xmlio's Path functionality because
> the "event dispatching" mostly removes the need for that.
>
> The problem at the moment is it brings with it so many inter and intra
> library dependencies that there isn't a light *distributable package*
> containing just the core Digester classes.
>
> I'm certainly not trying to criticise xmlio; I'm just concerned that
> multiple projects will both dilute the available developer pool and
> confuse potential users. And all that extra work - unit tests, project
> website, etc! If the projects are truly providing different
> functionality, well there's no issue. But as I understand xmlio now, I
> think that exactly the same goal can be achieved with almost exactly the
> same amount of custom code with both libs.
>
> Oliver: do you feel that the fact that Digester does "sax event
> dispatching" while xmlio doesn't really make the lib feel different to
> you? (honest question, it is a slightly different paradigm, like OO vs
> procedural). Is there something else that makes you feel Digester is
> fundamentally different from xmlio?
Simplicity and obviousness, having all parts of the code and the data
that are associated at one spot. Next is performance and actual
complexity of code. Next is amount of created objects.
Still, these are just considerations that come from my personal taste.
When rules become a bit more complicated, it might become pretty hard
to understand what is going on in the guts. A large block of if /
else statements might not be what people - including myself - would
call exactly elegant, but it is obvious with no secrets.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: XML Im-/Ex-porter into Commons Sandbox
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
>
> As I already tried to explain. Both are soooooo different. No need for
> any worries...
> They even serve a different audience I guess. Digester is good for
> people who do not want to see any XML stuff and what Java objects,
> with xmlio you are closer to the guts of SAX and XML.
I don't actually see that they are that different.
You can use Digester in a manner very similar to the way xmlio is used.
This is not the way Digester is "marketed" in its examples but it is
still quite valid:
class Foo {
private class HandleWidget extends Rule {
public void begin(...) {
// code to do stuff when a widget tag is found
}
}
...
digester.addRule("/root/widget", new HandleWidget());
digester.addRule("/root/gadget", new HandleGadget());
xmlReader.setContentHandler(digester);
xmlReader.parse(input);
}
Here's the xmlio equivalent (I think...)
class Foo {
private class MySimpleImportHandler implements SimpleImportHandler {
public void StartElement(...) {
if (path.equals("/root/widget) {
// code to do stuff when a widget tag is found
}
else if (path.equals("/root/gadget") {
// code to do stuff when a gadget tag is found
}
}
simpleImporter.addSimpleImportHandler(new MySimpleImportHandler());
saxParser.setContentHandler(simpleImporter);
saxParser.parse(input);
}
In other words, Digester *can* be used as a "light wrapper around SAX".
The begin/body/end methods of a custom Rule class are basically the SAX
callbacks; when using Digester in this style, Digester is really just an
"event dispatcher" routing each sax event from a single ContentHandler
class to zero or more relevant rule classes to avoid having big
cascading if/then statements in the ContentHandler class.
It wouldn't take too much work to provide xmlio's convenient feature of
passing the attributes into the body/end methods as well as the begin
method. It doesn't need to provide xmlio's Path functionality because
the "event dispatching" mostly removes the need for that.
The problem at the moment is it brings with it so many inter and intra
library dependencies that there isn't a light *distributable package*
containing just the core Digester classes.
I'm certainly not trying to criticise xmlio; I'm just concerned that
multiple projects will both dilute the available developer pool and
confuse potential users. And all that extra work - unit tests, project
website, etc! If the projects are truly providing different
functionality, well there's no issue. But as I understand xmlio now, I
think that exactly the same goal can be achieved with almost exactly the
same amount of custom code with both libs.
Oliver: do you feel that the fact that Digester does "sax event
dispatching" while xmlio doesn't really make the lib feel different to
you? (honest question, it is a slightly different paradigm, like OO vs
procedural). Is there something else that makes you feel Digester is
fundamentally different from xmlio?
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: XML Im-/Ex-porter into Commons Sandbox
Posted by Oliver Zeigermann <ol...@gmail.com>.
On Sat, 9 Oct 2004 07:59:53 +0100, robert burrell donkin
<ro...@blueyonder.co.uk> wrote:
> 3 alternatives are good but direct competitors are bad. we are short of
> developer energy here in the commons and components in the same area
> should share a community and coorperate rather than fight for mind
> share. fights for mind share between direct open source competitors can
> turn very nasty. we've (so far) managed to keep quite a healthy
> community here in the commons and i'm very keen to keep it this way.
> therefore, saying that xmlio needs a place in the commons because it's
> better than digester does make me worried. in the past, components
> pushed in this manner have tended to end up finding homes elsewhere.
Who said xmlio is better than digester? I have never even indicated
anything in that direction and Daniel said he perferred the xmlio
philisophy over digester. Really, no competition at all. Both work by
reading in XML and providing it to you in a transformed way and this
is where what they have in common ends.
> 4 users are going to ask: should i use digester (betwixt, JXPath,
> xmlbeans, jaxme) or xmlio? we should be able to clearly and fair
> describe and explain the differences if we are going to have two
> components. if digester and xmlio really are direct competitors (no
> substantial conceptual or philosophical differences, just
> implementation ones) then it would be better to rename xmlio digester 2
> (packaged under the org.apache.commons.digester2). digester (1) is
> mature now and it's not really possible to push it much further. work
> on a combined digester 1 replacement could then start as digester 3
> (packaged under rg.apache.commons.digester3).
As I already tried to explain. Both are soooooo different. No need for
any worries...
They even serve a different audience I guess. Digester is good for
people who do not want to see any XML stuff and what Java objects,
with xmlio you are closer to the guts of SAX and XML.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: XML Im-/Ex-porter into Commons Sandbox
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
a few comments:
1 in the sandbox, anything goes.
2 if i18n depends on xmlio then xmlio needs to promoted and released
before i18n is. so, it's important that xmlio has a good chance of
being promoted and that any possible issues are discussed now.
3 alternatives are good but direct competitors are bad. we are short of
developer energy here in the commons and components in the same area
should share a community and coorperate rather than fight for mind
share. fights for mind share between direct open source competitors can
turn very nasty. we've (so far) managed to keep quite a healthy
community here in the commons and i'm very keen to keep it this way.
therefore, saying that xmlio needs a place in the commons because it's
better than digester does make me worried. in the past, components
pushed in this manner have tended to end up finding homes elsewhere.
4 users are going to ask: should i use digester (betwixt, JXPath,
xmlbeans, jaxme) or xmlio? we should be able to clearly and fair
describe and explain the differences if we are going to have two
components. if digester and xmlio really are direct competitors (no
substantial conceptual or philosophical differences, just
implementation ones) then it would be better to rename xmlio digester 2
(packaged under the org.apache.commons.digester2). digester (1) is
mature now and it's not really possible to push it much further. work
on a combined digester 1 replacement could then start as digester 3
(packaged under rg.apache.commons.digester3).
- robert
On 7 Oct 2004, at 23:46, Martin Cooper wrote:
> On Thu, 7 Oct 2004 23:27:39 +0100, Stephen Colebourne
> <sc...@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" <gr...@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 <ol...@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
Re: XML Im-/Ex-porter into Commons Sandbox
Posted by James Mitchell <jm...@apache.org>.
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" <da...@web.de>
To: "'Jakarta Commons Developers List'" <co...@jakarta.apache.org>;
"'Martin Cooper'" <mf...@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
<sc...@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" <gr...@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 <ol...@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
[digester] AW: XML Im-/Ex-porter into Commons Sandbox
Posted by Daniel Florey <da...@web.de>.
The digester site seems to be broken. All links to the docs dont work
-----Ursprüngliche Nachricht-----
Von: commons-dev-return-60336-daniel.florey=web.de@jakarta.apache.org
[mailto:commons-dev-return-60336-daniel.florey=web.de@jakarta.apache.org] Im
Auftrag von Daniel Florey
Gesendet: Freitag, 8. Oktober 2004 09:32
An: 'Jakarta Commons Developers List'; 'Martin Cooper'
Betreff: 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
<sc...@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" <gr...@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 <ol...@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
AW: XML Im-/Ex-porter into Commons Sandbox
Posted by Daniel Florey <da...@web.de>.
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
<sc...@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" <gr...@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 <ol...@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
Re: XML Im-/Ex-porter into Commons Sandbox
Posted by Martin Cooper <mf...@gmail.com>.
On Thu, 7 Oct 2004 23:27:39 +0100, Stephen Colebourne
<sc...@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" <gr...@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 <ol...@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
Re: XML Im-/Ex-porter into Commons Sandbox
Posted by Oliver Zeigermann <ol...@gmail.com>.
Could be, but if it already works (with SAX I guess) and it is
maintainable there is not need for a change. xmlio just makes SAX so
much easier and convernient to use.
Oliver
On Fri, 8 Oct 2004 10:08:05 -0400, Noel J. Bergman <no...@devtech.com> wrote:
> Oliver Zeigermann wrote:
>
> > I understand your fears.
>
> > However, xmlio is not a mapper to Java objects, you just
> > receiver augmented SAX call backs.
>
> Is this something that could be pitched to Digester and XMLBeans to use
> under the covers? What would be the pros/cons of their adopting this
> package rather than their current code?
>
> --- Noel
>
>
>
>
> ---------------------------------------------------------------------
> 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
RE: XML Im-/Ex-porter into Commons Sandbox
Posted by "Noel J. Bergman" <no...@devtech.com>.
Oliver Zeigermann wrote:
> I understand your fears.
> However, xmlio is not a mapper to Java objects, you just
> receiver augmented SAX call backs.
Is this something that could be pitched to Digester and XMLBeans to use
under the covers? What would be the pros/cons of their adopting this
package rather than their current code?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: XML Im-/Ex-porter into Commons Sandbox
Posted by Oliver Zeigermann <ol...@gmail.com>.
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
<ol...@gmail.com> 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
> <sc...@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.
> >
> > 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" <gr...@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 <ol...@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
Re: XML Im-/Ex-porter into Commons Sandbox
Posted by Oliver Zeigermann <ol...@gmail.com>.
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
<sc...@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.
>
> 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" <gr...@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 <ol...@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
Re: XML Im-/Ex-porter into Commons Sandbox
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Fri, 2004-10-08 at 11:27, Stephen Colebourne 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.
I'll certainly have a look at the code to see how it compares with
Digester. Like some others I am concerned by the large number of
xml->java facilities around (and not just Apache ones), and am not sure
the world needs another one. But I know the Slide team are pretty smart,
so I'm very curious what this alternative "simple" approach is..
> Finally, the name ;-)
> xmlio (ie. xml io)
> sax
> saxio
saxy? :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: XML Im-/Ex-porter into Commons Sandbox
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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" <gr...@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 <ol...@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
Re: XML Im-/Ex-porter into Commons Sandbox
Posted by David Graham <gr...@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 <ol...@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,
>
> Oliver
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org