You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Jukka Zitting <ju...@gmail.com> on 2008/12/17 14:09:00 UTC
Proposal: Commons SAX
Hi,
In the Apache Tika project [1] we use SAX quite a lot, and have
written a set of quite useful general utility classes for SAX
handling.
For example, in org.apache.tika.sax [2] we have the following:
* ContentHandlerDecorator - Convenient base class for writing
ContentHandler decorators
* EmbeddedContentHandler - Decorator that blocks startDocument() and
endDocument() calls
* TeeContentHandler - Forwards SAX events to multiple handlers
* TextContentHandler - Decorator that blocks everything but character
events (and start/endDocument)
* WriteOutContentHandler - Writes the contents of all character events
to a Writer
In org.apache.tika.sax.xpath [3] we have a simple XPath subset
implementation that supports streaming and filtering of SAX events. In
other words, the implementation doesn't need a DOM tree to evaluate
XPath statements.
I believe this code would be useful also outside Tika, and I was
thinking that it might perhaps make sense to create a Commons project
for this. I also know of some SAX processing classes in Cocoon and
Jackrabbit that could well be of interest to a wider audience.
Do you think something like this would be interesting as a Commons
project? Are there other similar efforts that I should know of? I
looked at XML Commons in xml.apache.org, but it seems pretty dormant.
[1] http://lucene.apache.org/tika/
[2] http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/package-summary.html
[3] http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/xpath/package-summary.html
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Proposal: Commons SAX
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
FOP basically does all its XML parsing based on SAX. I don't see too
much overlap right now (without looking more closely). But maybe someone
can see something worth copying/moving in such a Commons SAX. A
colleague of mine had to implement something like a TeeContentHandler a
few weeks ago. So I guess there are use cases for things like that.
Here's a link to the SAX utility classes we have in FOP if anyone is
interested:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/util/
Relevant classes:
ContentHandlerFactory (used for handling embedded non-FO documents)
ContentHandlerFactoryRegistry
DOMBuilderContentHandlerFactory
DelegatingContentHandler
DOM2SAX (adapted from Xalan)
That was mostly the parsing side, but generating XML by generating SAX
events can also be very interesting and most of all damn fast and
versatile. Pure SAX method calls for generating XML are very verbose and
in many cases unnecessary. FOP's example code contains something I wrote
a long time ago.
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/tools/
I'm doing that differently today but I'm still not 100% happy. I've
written some new code in a dev branch I'm currently working in:
http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_AreaTreeNewDesign/src/java/org/apache/fop/util/
Relevant classes:
GenerationHelperContentHandler
XMLConstants
XMLUtil
Example using the above classes:
http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_AreaTreeNewDesign/src/sandbox/org/apache/fop/render/svg/SVGPainter.java?view=markup
In XML Graphics Commons, there's the interface XMLizable:
http://svn.apache.org/viewvc/xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/util/XMLizable.java?view=markup
which I've used a number of times. Basically, I've stolen that from
Excalibur/Cocoon:
http://excalibur.apache.org/apidocs/org/apache/excalibur/xml/sax/XMLizable.html
Says by itself that this is obviously useful.
Another handy utility is javax.xml.namespace.QName which is found
starting in Java 1.5. Since XML Graphics is still on Java 1.4 I've
written a similar class:
http://svn.apache.org/viewvc/xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/util/QName.java?view=markup
So, I'm just listing what comes to my mind. No idea what is useful. At
any rate, the Commons SAX idea is a good one IMO. I'd be happy to help
out depending on the scope (i.e. for what there is room).
On 17.12.2008 14:09:00 Jukka Zitting wrote:
> Hi,
>
> In the Apache Tika project [1] we use SAX quite a lot, and have
> written a set of quite useful general utility classes for SAX
> handling.
>
> For example, in org.apache.tika.sax [2] we have the following:
>
> * ContentHandlerDecorator - Convenient base class for writing
> ContentHandler decorators
> * EmbeddedContentHandler - Decorator that blocks startDocument() and
> endDocument() calls
> * TeeContentHandler - Forwards SAX events to multiple handlers
> * TextContentHandler - Decorator that blocks everything but character
> events (and start/endDocument)
> * WriteOutContentHandler - Writes the contents of all character events
> to a Writer
>
> In org.apache.tika.sax.xpath [3] we have a simple XPath subset
> implementation that supports streaming and filtering of SAX events. In
> other words, the implementation doesn't need a DOM tree to evaluate
> XPath statements.
>
> I believe this code would be useful also outside Tika, and I was
> thinking that it might perhaps make sense to create a Commons project
> for this. I also know of some SAX processing classes in Cocoon and
> Jackrabbit that could well be of interest to a wider audience.
>
> Do you think something like this would be interesting as a Commons
> project? Are there other similar efforts that I should know of? I
> looked at XML Commons in xml.apache.org, but it seems pretty dormant.
>
> [1] http://lucene.apache.org/tika/
> [2] http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/package-summary.html
> [3] http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/xpath/package-summary.html
>
> BR,
>
> Jukka Zitting
>
Jeremias Maerki
Re: Proposal: Commons SAX
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Dec 18, 2008 at 9:25 AM, Jeremias Maerki <de...@jeremias-maerki.ch> wrote:
> Oversight/Responsibility over XML Commons has been transferred to the
> Xerces PMC in November 2006. The XML project itself is subject to be
> killed as soon as the last issues (AxKit & XIndice) have been dealt with.
> Xerces is currently just using XML Commons to maintain the XML APIs. Not
> much else is going on there. So if this is no good fit for Apache
> Commons, we'd have to talk to the Xerces people.
I pinged the Xerces people about this.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Proposal: Commons SAX
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Oversight/Responsibility over XML Commons has been transferred to the
Xerces PMC in November 2006. The XML project itself is subject to be
killed as soon as the last issues (AxKit & XIndice) have been dealt with.
Xerces is currently just using XML Commons to maintain the XML APIs. Not
much else is going on there. So if this is no good fit for Apache
Commons, we'd have to talk to the Xerces people.
On 18.12.2008 07:40:26 Martin Cooper wrote:
> "I looked at XML Commons in xml.apache.org, but it seems pretty dormant."
>
> Perhaps this would be an opportunity to re-vitalize it? I really dislike the
> implication that Commons should accept a new project simply because a more
> appropriate parent project wasn't paying attention.
>
> --
> Martin Cooper
>
>
> On Wed, Dec 17, 2008 at 5:09 AM, Jukka Zitting <ju...@gmail.com>wrote:
>
> > Hi,
> >
> > In the Apache Tika project [1] we use SAX quite a lot, and have
> > written a set of quite useful general utility classes for SAX
> > handling.
> >
> > For example, in org.apache.tika.sax [2] we have the following:
> >
> > * ContentHandlerDecorator - Convenient base class for writing
> > ContentHandler decorators
> > * EmbeddedContentHandler - Decorator that blocks startDocument() and
> > endDocument() calls
> > * TeeContentHandler - Forwards SAX events to multiple handlers
> > * TextContentHandler - Decorator that blocks everything but character
> > events (and start/endDocument)
> > * WriteOutContentHandler - Writes the contents of all character events
> > to a Writer
> >
> > In org.apache.tika.sax.xpath [3] we have a simple XPath subset
> > implementation that supports streaming and filtering of SAX events. In
> > other words, the implementation doesn't need a DOM tree to evaluate
> > XPath statements.
> >
> > I believe this code would be useful also outside Tika, and I was
> > thinking that it might perhaps make sense to create a Commons project
> > for this. I also know of some SAX processing classes in Cocoon and
> > Jackrabbit that could well be of interest to a wider audience.
> >
> > Do you think something like this would be interesting as a Commons
> > project? Are there other similar efforts that I should know of? I
> > looked at XML Commons in xml.apache.org, but it seems pretty dormant.
> >
> > [1] http://lucene.apache.org/tika/
> > [2]
> > http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/package-summary.html
> > [3]
> > http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/xpath/package-summary.html
> >
> > BR,
> >
> > Jukka Zitting
> >
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Proposal: Commons SAX
Posted by Martin Cooper <ma...@apache.org>.
"I looked at XML Commons in xml.apache.org, but it seems pretty dormant."
Perhaps this would be an opportunity to re-vitalize it? I really dislike the
implication that Commons should accept a new project simply because a more
appropriate parent project wasn't paying attention.
--
Martin Cooper
On Wed, Dec 17, 2008 at 5:09 AM, Jukka Zitting <ju...@gmail.com>wrote:
> Hi,
>
> In the Apache Tika project [1] we use SAX quite a lot, and have
> written a set of quite useful general utility classes for SAX
> handling.
>
> For example, in org.apache.tika.sax [2] we have the following:
>
> * ContentHandlerDecorator - Convenient base class for writing
> ContentHandler decorators
> * EmbeddedContentHandler - Decorator that blocks startDocument() and
> endDocument() calls
> * TeeContentHandler - Forwards SAX events to multiple handlers
> * TextContentHandler - Decorator that blocks everything but character
> events (and start/endDocument)
> * WriteOutContentHandler - Writes the contents of all character events
> to a Writer
>
> In org.apache.tika.sax.xpath [3] we have a simple XPath subset
> implementation that supports streaming and filtering of SAX events. In
> other words, the implementation doesn't need a DOM tree to evaluate
> XPath statements.
>
> I believe this code would be useful also outside Tika, and I was
> thinking that it might perhaps make sense to create a Commons project
> for this. I also know of some SAX processing classes in Cocoon and
> Jackrabbit that could well be of interest to a wider audience.
>
> Do you think something like this would be interesting as a Commons
> project? Are there other similar efforts that I should know of? I
> looked at XML Commons in xml.apache.org, but it seems pretty dormant.
>
> [1] http://lucene.apache.org/tika/
> [2]
> http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/package-summary.html
> [3]
> http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/xpath/package-summary.html
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Fwd: Proposal: Commons SAX
Posted by Ralph Goers <ra...@dslextreme.com>.
Just in case you didn't see it, Jukka has set up a project at https://svn.apache.org/repos/asf/commons/sandbox/xml
.
Ralph
Begin forwarded message:
> From: Henri Yandell <fl...@gmail.com>
> Date: February 5, 2009 10:27:51 PM PST
> To: Commons Developers List <de...@commons.apache.org>
> Subject: Re: Proposal: Commons SAX
> Reply-To: "Commons Developers List" <de...@commons.apache.org>
>
> On Wed, Dec 31, 2008 at 1:25 PM, Rahul Akolkar <rahul.akolkar@gmail.com
> > wrote:
>> On Wed, Dec 31, 2008 at 8:55 AM, Jukka Zitting <jukka.zitting@gmail.com
>> > wrote:
>>> Hi,
>>>
>>> Until we come up with consensus on where (Commons, Xerces or Cocoon)
>>> we should place this proposed library, I'd like to start putting
>>> some
>>> bits together in the Commons Sandbox.
>>>
>>> The Commons web page defines the Sandbox as "a place to try out new
>>> ideas and prepare for inclusion into the Commons portion of the
>>> project [*] or into another Apache project", which is exactly what
>>> I'm
>>> planning to do.
>>>
>>> [*] Is this wording a leftover from Jakarta days?
>>>
>> <snip/>
>>
>> No, thats right. You can start in the Sandbox, consensus would be
>> needed if you propose addition to Proper (there are no releases out
>> of
>> the Sandbox, so at some point you'd need to find the code a better
>> home).
>
> Additionally, any committers at Tika or Cocoon who want commit access
> to this just has to pipe up and they'll be added to the sandbox karma.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Re: Proposal: Commons SAX
Posted by Henri Yandell <fl...@gmail.com>.
On Wed, Dec 31, 2008 at 1:25 PM, Rahul Akolkar <ra...@gmail.com> wrote:
> On Wed, Dec 31, 2008 at 8:55 AM, Jukka Zitting <ju...@gmail.com> wrote:
>> Hi,
>>
>> Until we come up with consensus on where (Commons, Xerces or Cocoon)
>> we should place this proposed library, I'd like to start putting some
>> bits together in the Commons Sandbox.
>>
>> The Commons web page defines the Sandbox as "a place to try out new
>> ideas and prepare for inclusion into the Commons portion of the
>> project [*] or into another Apache project", which is exactly what I'm
>> planning to do.
>>
>> [*] Is this wording a leftover from Jakarta days?
>>
> <snip/>
>
> No, thats right. You can start in the Sandbox, consensus would be
> needed if you propose addition to Proper (there are no releases out of
> the Sandbox, so at some point you'd need to find the code a better
> home).
Additionally, any committers at Tika or Cocoon who want commit access
to this just has to pipe up and they'll be added to the sandbox karma.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Proposal: Commons SAX
Posted by Rahul Akolkar <ra...@gmail.com>.
On Wed, Dec 31, 2008 at 8:55 AM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> Until we come up with consensus on where (Commons, Xerces or Cocoon)
> we should place this proposed library, I'd like to start putting some
> bits together in the Commons Sandbox.
>
> The Commons web page defines the Sandbox as "a place to try out new
> ideas and prepare for inclusion into the Commons portion of the
> project [*] or into another Apache project", which is exactly what I'm
> planning to do.
>
> [*] Is this wording a leftover from Jakarta days?
>
<snip/>
No, thats right. You can start in the Sandbox, consensus would be
needed if you propose addition to Proper (there are no releases out of
the Sandbox, so at some point you'd need to find the code a better
home).
For Commons, we're interested in (this is from the old charter [1],
but it still holds IMO):
"Each package must have a clearly defined purpose, scope, and API --
Do one thing well, and keep your contracts."
The best place to capture the purpose and scope is probably via a
PROPOSAL document in SVN trunk, so I recommend new components have
one. See recent examples [2, 3].
-Rahul
[1] http://commons.apache.org/oldcharter.html (first FAQ)
[2] http://svn.apache.org/repos/asf/commons/sandbox/monitoring/trunk/PROPOSAL.html
[3] http://svn.apache.org/repos/asf/commons/sandbox/me/trunk/PROPOSAL.html
> BR,
>
> Jukka Zitting
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Proposal: Commons SAX
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Dec 31, 2008 at 2:55 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Until we come up with consensus on where (Commons, Xerces or Cocoon)
> we should place this proposed library, I'd like to start putting some
> bits together in the Commons Sandbox.
I've now set up a project skeleton at
https://svn.apache.org/repos/asf/commons/sandbox/xml.
See below for the PROPOSAL I wrote for this effort.
I'll be adding some initial code from various sources in the next few
weeks. Feel free to jump in if you're interested.
BR,
Jukka Zitting
====================================
Proposal for the Commons XML Package
====================================
0. Rationale
------------
Many Apache projects have implemented utility classes for working with
XML documents and the Java API for XML Processing (JAXP) interfaces. These
classes can encapsulate years of experience with XML processing, but they
can be hard to find and reuse outside the originating project. It would be
beneficial to have a well maintained shared library of such code.
Various Apache projects like Xerces and Cocoon have been suggested as
appropriate places where such a shared library could be developed and
maintained. No clear consensus has however been reached on this matter.
For now the plan is to just start collecting initial code and interested
contributors in the Commons sandbox. We can revisit the question of the
eventual location of this codebase once it is clearer what code will be
included and who are most interested in developing and maintaining the code.
1. Scope of the Package
------------------------
The Commons XML package will contain utility code designed to make
working with JAXP easier. The goal is to work with the existing JAXP
infrastructure instead of trying to come up with an alternative.
1.5 Interaction With Other Packages
The Commons XML package will depend only on the Java 5 platform and the JAXP
interfaces included in it. No external dependencies or configuration files
will be used.
2. Initial Source of the Package
--------------------------------
The initial code of the Commmons XML package will be collected from
various Apache projects like Tika, Cocoon and Jackrabbit.
The code will be placed within the org.apache.commons.xml package.
Subpackages for specific types of code like SAX or DOM utilities will
be created as appropriate.
3. Required Commons Resources
-----------------------------
Version Control
The Commons XML codebase is located in the "xml" directory
inside the Commons Sandbox tree. The codebase can be found at:
https://svn.apache.org/repos/asf/commons/sandbox/xml/trunk/
Mailing List
Discussions about the Commons XML package will take place on the
dev@commons.apache.org mailing list. The subject lines of related
messages should prefixed with [xml].
Issue Tracker
No issue tracker will be set up for now. We can decide where and
how to track issues once the future location of the package becomes
clearer.
4. Initial Committers
---------------------
The proposal is currently being driven by Jukka Zitting, but any
Apache committer is welcome to join the effort.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Proposal: Commons SAX
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
Until we come up with consensus on where (Commons, Xerces or Cocoon)
we should place this proposed library, I'd like to start putting some
bits together in the Commons Sandbox.
The Commons web page defines the Sandbox as "a place to try out new
ideas and prepare for inclusion into the Commons portion of the
project [*] or into another Apache project", which is exactly what I'm
planning to do.
[*] Is this wording a leftover from Jakarta days?
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Proposal: Commons SAX
Posted by Carsten Ziegeler <cz...@apache.org>.
Jeremias Maerki wrote:
> Frankly, I don't believe Cocoon is the right place. It's too high-level.
> IMO, this should either be Commons or XML Commons.
>
While I don't think that Cocoon is too high level for this, I actually don't
care that much where the code is hosted. As long as I'm able to commit
and it doesn't take ages to get a release out.
At the moment, we have two code bases, one at Cocoon at one at Tika. So
it might make sense, to first see if we can merge the two and then find
a place?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Proposal: Commons SAX
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Frankly, I don't believe Cocoon is the right place. It's too high-level.
IMO, this should either be Commons or XML Commons.
On 02.01.2009 09:11:52 Carsten Ziegeler wrote:
> Jukka Zitting wrote:
> > Hi,
> >
> > On Mon, Dec 29, 2008 at 9:56 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> >> In the Cocoon project we're about to refactor/move some of our common
> >> xml stuff into an own sub project at Cocoon. This will be a small
> >> reusable library. So maybe we could add the common stuff from Tika there
> >> as well. We have a huge xml community already within the Cocoon project.
> >
> > That's another good option. How would Cocoon handle people who are
> > interested in working on this code but not on other parts of Cocoon?
> >
> Good question :) We haven't discussed this yet, but I guess we would
> just make them committers.
>
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Proposal: Commons SAX
Posted by Carsten Ziegeler <cz...@apache.org>.
Jukka Zitting wrote:
> Hi,
>
> On Mon, Dec 29, 2008 at 9:56 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> In the Cocoon project we're about to refactor/move some of our common
>> xml stuff into an own sub project at Cocoon. This will be a small
>> reusable library. So maybe we could add the common stuff from Tika there
>> as well. We have a huge xml community already within the Cocoon project.
>
> That's another good option. How would Cocoon handle people who are
> interested in working on this code but not on other parts of Cocoon?
>
Good question :) We haven't discussed this yet, but I guess we would
just make them committers.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Proposal: Commons SAX
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, Dec 29, 2008 at 9:56 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> In the Cocoon project we're about to refactor/move some of our common
> xml stuff into an own sub project at Cocoon. This will be a small
> reusable library. So maybe we could add the common stuff from Tika there
> as well. We have a huge xml community already within the Cocoon project.
That's another good option. How would Cocoon handle people who are
interested in working on this code but not on other parts of Cocoon?
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Proposal: Commons SAX
Posted by Carsten Ziegeler <cz...@apache.org>.
Jukka Zitting wrote:
> I believe this code would be useful also outside Tika, and I was
> thinking that it might perhaps make sense to create a Commons project
> for this. I also know of some SAX processing classes in Cocoon and
> Jackrabbit that could well be of interest to a wider audience.
>
> Do you think something like this would be interesting as a Commons
> project? Are there other similar efforts that I should know of? I
> looked at XML Commons in xml.apache.org, but it seems pretty dormant.
>
In the Cocoon project we're about to refactor/move some of our common
xml stuff into an own sub project at Cocoon. This will be a small
reusable library. So maybe we could add the common stuff from Tika there
as well. We have a huge xml community already within the Cocoon project.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Proposal: Commons SAX
Posted by Paul Libbrecht <pa...@activemath.org>.
It may be worth quoting that:
- it's livable to be registered to commons-dev without filter (you
need a swift delete key)
- the filter practice is deep anchored until the netiquette for both
commons-dev and commons-user so that mails without the project prefix
are very quickly warned about and corrected
paul
Le 29-déc.-08 à 04:56, Henri Yandell a écrit :
> I don't see why it's not a good fit for Commons. We've a few xml
> related components in the dormant section. I think a component with
> things for both SAX and DOM would be fine, and letting it grow
> organically would also work well.
>
> Hen
>
> On Wed, Dec 17, 2008 at 5:09 AM, Jukka Zitting <jukka.zitting@gmail.com
> > wrote:
>> Hi,
>>
>> In the Apache Tika project [1] we use SAX quite a lot, and have
>> written a set of quite useful general utility classes for SAX
>> handling.
>>
>> For example, in org.apache.tika.sax [2] we have the following:
>>
>> * ContentHandlerDecorator - Convenient base class for writing
>> ContentHandler decorators
>> * EmbeddedContentHandler - Decorator that blocks startDocument() and
>> endDocument() calls
>> * TeeContentHandler - Forwards SAX events to multiple handlers
>> * TextContentHandler - Decorator that blocks everything but character
>> events (and start/endDocument)
>> * WriteOutContentHandler - Writes the contents of all character
>> events
>> to a Writer
>>
>> In org.apache.tika.sax.xpath [3] we have a simple XPath subset
>> implementation that supports streaming and filtering of SAX events.
>> In
>> other words, the implementation doesn't need a DOM tree to evaluate
>> XPath statements.
>>
>> I believe this code would be useful also outside Tika, and I was
>> thinking that it might perhaps make sense to create a Commons project
>> for this. I also know of some SAX processing classes in Cocoon and
>> Jackrabbit that could well be of interest to a wider audience.
>>
>> Do you think something like this would be interesting as a Commons
>> project? Are there other similar efforts that I should know of? I
>> looked at XML Commons in xml.apache.org, but it seems pretty dormant.
>>
>> [1] http://lucene.apache.org/tika/
>> [2] http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/package-summary.html
>> [3] http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/xpath/package-summary.html
>>
>> BR,
>>
>> Jukka Zitting
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Proposal: Commons SAX
Posted by David Crossley <cr...@apache.org>.
Michael Glavassevich wrote:
> Ralph Goers wrote:
> > someone wrote:
> > >
> > > As part of the gradual shutdown of the XML project, the Xerces PMC has
> > > agreed some time ago to take over the responsibility for XML Commons.
> > > The xml-commons group which you mentioned is basically for committers
> > > who only have access to XML commons (mainly Norman Walsh when he still
> > > worked on the resolver). Today XML Commons is write-accessible for
> > > committers from various projects (Xerces, Xalan, XML Graphics, Cocoon,
> > > Forrest etc.). But they don't use that karma very often. Yes, it
> > > doesn't
> > > have much of a community mainly because the various parts are mostly
> > > "too stable". We can change that by reactivating XML Commons with new
> > > goals.
> > >
> > > The virtual link you mentioned is a good idea IMO and seems in line
> > > with Henri's ideas of a federated Commons.
> >
> > Interesting. What is the XML PMC group for? As a Cocoon committer I
> > recall having commit privs on xml years ago. I don't believe we do
> > anymore though.
>
> When XML Commons was transferred over to the Xerces PMC I don't believe
> anything changed with respect to who has commit privileges. At least there
> was no intention of removing anyone.
Yes, other projects can still commit to "xml-commons", currently:
xml-pmc cocoon forrest lenya xalan xerces xerces-j xml-commons xml-xindice xmlgraphics-batik xmlgraphics-fop
The Xerces PMC could enable other project groups to
have authorisation too.
> I'm not sure how one checks who
> actually has write-access, but I suspect the list includes many folks
> who've never committed to the project before and possibly aren't aware that
> they can.
http://www.apache.org/dev/#pmc
... http://www.apache.org/dev/pmc.html#newcommitter-svn
That paragraph mentions the Subversion authorization URL.
> > At least, http://people.apache.org/~jim/committers.html doesn't
> > reflect it.
There must be some lack with the script to build Jim's pages,
as http://people.apache.org/~jim/projects.html#xml-commons
just shows a basic group of extra people.
The script is in his home directory if someone can make
a patch for him.
-David
> > I suspect there is some cocoon stuff that really should
> > find a home here eventually as well.
>
> Cool.
>
> > Ralph
>
> Thanks.
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Proposal: Commons SAX
Posted by David Crossley <cr...@apache.org>.
Michael Glavassevich wrote:
> Ralph Goers wrote:
> > someone wrote:
> > >
> > > As part of the gradual shutdown of the XML project, the Xerces PMC has
> > > agreed some time ago to take over the responsibility for XML Commons.
> > > The xml-commons group which you mentioned is basically for committers
> > > who only have access to XML commons (mainly Norman Walsh when he still
> > > worked on the resolver). Today XML Commons is write-accessible for
> > > committers from various projects (Xerces, Xalan, XML Graphics, Cocoon,
> > > Forrest etc.). But they don't use that karma very often. Yes, it
> > > doesn't
> > > have much of a community mainly because the various parts are mostly
> > > "too stable". We can change that by reactivating XML Commons with new
> > > goals.
> > >
> > > The virtual link you mentioned is a good idea IMO and seems in line
> > > with Henri's ideas of a federated Commons.
> >
> > Interesting. What is the XML PMC group for? As a Cocoon committer I
> > recall having commit privs on xml years ago. I don't believe we do
> > anymore though.
>
> When XML Commons was transferred over to the Xerces PMC I don't believe
> anything changed with respect to who has commit privileges. At least there
> was no intention of removing anyone.
Yes, other projects can still commit to "xml-commons", currently:
xml-pmc cocoon forrest lenya xalan xerces xerces-j xml-commons xml-xindice xmlgraphics-batik xmlgraphics-fop
The Xerces PMC could enable other project groups to
have authorisation too.
> I'm not sure how one checks who
> actually has write-access, but I suspect the list includes many folks
> who've never committed to the project before and possibly aren't aware that
> they can.
http://www.apache.org/dev/#pmc
... http://www.apache.org/dev/pmc.html#newcommitter-svn
That paragraph mentions the Subversion authorization URL.
> > At least, http://people.apache.org/~jim/committers.html doesn't
> > reflect it.
There must be some lack with the script to build Jim's pages,
as http://people.apache.org/~jim/projects.html#xml-commons
just shows a basic group of extra people.
The script is in his home directory if someone can make
a patch for him.
-David
> > I suspect there is some cocoon stuff that really should
> > find a home here eventually as well.
>
> Cool.
>
> > Ralph
>
> Thanks.
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
Re: Proposal: Commons SAX
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Ralph Goers <ra...@dslextreme.com> wrote on 12/29/2008 02:36:30 PM:
> On Dec 29, 2008, at 9:51 AM, Jeremias Maerki wrote:
>
> > As part of the gradual shutdown of the XML project, the Xerces PMC has
> > agreed some time ago to take over the responsibility for XML Commons.
> > The xml-commons group which you mentioned is basically for committers
> > who only have access to XML commons (mainly Norman Walsh when he still
> > worked on the resolver). Today XML Commons is write-accessible for
> > committers from various projects (Xerces, Xalan, XML Graphics, Cocoon,
> > Forrest etc.). But they don't use that karma very often. Yes, it
> > doesn't
> > have much of a community mainly because the various parts are mostly
> > "too stable". We can change that by reactivating XML Commons with new
> > goals.
> >
> > The virtual link you mentioned is a good idea IMO and seems in line
> > with
> > Henri's ideas of a federated Commons.
> >
>
> Interesting. What is the XML PMC group for? As a Cocoon committer I
> recall having commit privs on xml years ago. I don't believe we do
> anymore though.
When XML Commons was transferred over to the Xerces PMC I don't believe
anything changed with respect to who has commit privileges. At least there
was no intention of removing anyone. I'm not sure how one checks who
actually has write-access, but I suspect the list includes many folks
who've never committed to the project before and possibly aren't aware that
they can.
> At least, http://people.apache.org/~jim/ committers.html doesn't
> reflect it. I suspect there is some cocoon stuff that really should
> find a home here eventually as well.
Cool.
> Ralph
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Re: Proposal: Commons SAX
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Ralph Goers <ra...@dslextreme.com> wrote on 12/29/2008 02:36:30 PM:
> On Dec 29, 2008, at 9:51 AM, Jeremias Maerki wrote:
>
> > As part of the gradual shutdown of the XML project, the Xerces PMC has
> > agreed some time ago to take over the responsibility for XML Commons.
> > The xml-commons group which you mentioned is basically for committers
> > who only have access to XML commons (mainly Norman Walsh when he still
> > worked on the resolver). Today XML Commons is write-accessible for
> > committers from various projects (Xerces, Xalan, XML Graphics, Cocoon,
> > Forrest etc.). But they don't use that karma very often. Yes, it
> > doesn't
> > have much of a community mainly because the various parts are mostly
> > "too stable". We can change that by reactivating XML Commons with new
> > goals.
> >
> > The virtual link you mentioned is a good idea IMO and seems in line
> > with
> > Henri's ideas of a federated Commons.
> >
>
> Interesting. What is the XML PMC group for? As a Cocoon committer I
> recall having commit privs on xml years ago. I don't believe we do
> anymore though.
When XML Commons was transferred over to the Xerces PMC I don't believe
anything changed with respect to who has commit privileges. At least there
was no intention of removing anyone. I'm not sure how one checks who
actually has write-access, but I suspect the list includes many folks
who've never committed to the project before and possibly aren't aware that
they can.
> At least, http://people.apache.org/~jim/ committers.html doesn't
> reflect it. I suspect there is some cocoon stuff that really should
> find a home here eventually as well.
Cool.
> Ralph
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Re: Proposal: Commons SAX
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 29, 2008, at 9:51 AM, Jeremias Maerki wrote:
> As part of the gradual shutdown of the XML project, the Xerces PMC has
> agreed some time ago to take over the responsibility for XML Commons.
> The xml-commons group which you mentioned is basically for committers
> who only have access to XML commons (mainly Norman Walsh when he still
> worked on the resolver). Today XML Commons is write-accessible for
> committers from various projects (Xerces, Xalan, XML Graphics, Cocoon,
> Forrest etc.). But they don't use that karma very often. Yes, it
> doesn't
> have much of a community mainly because the various parts are mostly
> "too stable". We can change that by reactivating XML Commons with new
> goals.
>
> The virtual link you mentioned is a good idea IMO and seems in line
> with
> Henri's ideas of a federated Commons.
>
Interesting. What is the XML PMC group for? As a Cocoon committer I
recall having commit privs on xml years ago. I don't believe we do
anymore though. At least, http://people.apache.org/~jim/
committers.html doesn't reflect it. I suspect there is some cocoon
stuff that really should find a home here eventually as well.
Ralph
Re: Proposal: Commons SAX
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 29, 2008, at 9:51 AM, Jeremias Maerki wrote:
> As part of the gradual shutdown of the XML project, the Xerces PMC has
> agreed some time ago to take over the responsibility for XML Commons.
> The xml-commons group which you mentioned is basically for committers
> who only have access to XML commons (mainly Norman Walsh when he still
> worked on the resolver). Today XML Commons is write-accessible for
> committers from various projects (Xerces, Xalan, XML Graphics, Cocoon,
> Forrest etc.). But they don't use that karma very often. Yes, it
> doesn't
> have much of a community mainly because the various parts are mostly
> "too stable". We can change that by reactivating XML Commons with new
> goals.
>
> The virtual link you mentioned is a good idea IMO and seems in line
> with
> Henri's ideas of a federated Commons.
>
Interesting. What is the XML PMC group for? As a Cocoon committer I
recall having commit privs on xml years ago. I don't believe we do
anymore though. At least, http://people.apache.org/~jim/
committers.html doesn't reflect it. I suspect there is some cocoon
stuff that really should find a home here eventually as well.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Proposal: Commons SAX
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
As part of the gradual shutdown of the XML project, the Xerces PMC has
agreed some time ago to take over the responsibility for XML Commons.
The xml-commons group which you mentioned is basically for committers
who only have access to XML commons (mainly Norman Walsh when he still
worked on the resolver). Today XML Commons is write-accessible for
committers from various projects (Xerces, Xalan, XML Graphics, Cocoon,
Forrest etc.). But they don't use that karma very often. Yes, it doesn't
have much of a community mainly because the various parts are mostly
"too stable". We can change that by reactivating XML Commons with new
goals.
The virtual link you mentioned is a good idea IMO and seems in line with
Henri's ideas of a federated Commons.
On 29.12.2008 15:55:33 Ralph Goers wrote:
>
> On Dec 29, 2008, at 6:20 AM, Jeremias Maerki wrote:
>
> > See:
> > http://markmail.org/message/i4mzckmqzy2gdwsc
> >
> > Xerces (responsible for XML Commons) seems open to revive XML
> > Commons a
> > bit. I think it would make sense to do Commons SAX or Commons XML in
> > XML
> > Commons, not here. I'm planning to invest some time in this after New
> > Year.
> >
>
> I agree that xml commons seems like the appropriate place although it
> would made sense to have a "virtual" commons xml project that is a
> link to xml commons just so people can find it either way. The only
> problem I see with xml commons is that it doesn't seem to have a
> community at present. I'm not sure why the Xerces PMC is managing xml
> commons. http://people.apache.org/~jim/projects.html#xml-commons
> would lead one to believe that it is managed by the XML PMC. Yet I do
> see that the board report seems to be coming from the Xerces PMC.
>
> However, given the interest I'm sure this could all be straightened out.
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Proposal: Commons SAX
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 29, 2008, at 6:20 AM, Jeremias Maerki wrote:
> See:
> http://markmail.org/message/i4mzckmqzy2gdwsc
>
> Xerces (responsible for XML Commons) seems open to revive XML
> Commons a
> bit. I think it would make sense to do Commons SAX or Commons XML in
> XML
> Commons, not here. I'm planning to invest some time in this after New
> Year.
>
I agree that xml commons seems like the appropriate place although it
would made sense to have a "virtual" commons xml project that is a
link to xml commons just so people can find it either way. The only
problem I see with xml commons is that it doesn't seem to have a
community at present. I'm not sure why the Xerces PMC is managing xml
commons. http://people.apache.org/~jim/projects.html#xml-commons
would lead one to believe that it is managed by the XML PMC. Yet I do
see that the board report seems to be coming from the Xerces PMC.
However, given the interest I'm sure this could all be straightened out.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Proposal: Commons SAX
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
See:
http://markmail.org/message/i4mzckmqzy2gdwsc
Xerces (responsible for XML Commons) seems open to revive XML Commons a
bit. I think it would make sense to do Commons SAX or Commons XML in XML
Commons, not here. I'm planning to invest some time in this after New
Year.
On 29.12.2008 12:07:14 Paul Libbrecht wrote:
> Erm... what about xml-commons ?
> http://xml.apache.org/commons/
>
> is this considered dropped?
> At least another project that's in the realm of xml-commons is xml-
> resolver, or?
>
> Would that migrate in as well? It could but...
>
> paul
>
>
> Le 29-déc.-08 à 11:06, Jochen Wiedmann a écrit :
>
> > On Mon, Dec 29, 2008 at 4:56 AM, Henri Yandell <fl...@gmail.com>
> > wrote:
> >
> >> I don't see why it's not a good fit for Commons. We've a few xml
> >> related components in the dormant section. I think a component with
> >> things for both SAX and DOM would be fine, and letting it grow
> >> organically would also work well.
> >
> > Ok, but lets suggest another name like Commons XML. For example, this
> > might be a good place for SAX -> StAX converters and stuff like that.
> > No sense in restricting it to SAX by name.
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Proposal: Commons SAX
Posted by Paul Libbrecht <pa...@activemath.org>.
Erm... what about xml-commons ?
http://xml.apache.org/commons/
is this considered dropped?
At least another project that's in the realm of xml-commons is xml-
resolver, or?
Would that migrate in as well? It could but...
paul
Le 29-déc.-08 à 11:06, Jochen Wiedmann a écrit :
> On Mon, Dec 29, 2008 at 4:56 AM, Henri Yandell <fl...@gmail.com>
> wrote:
>
>> I don't see why it's not a good fit for Commons. We've a few xml
>> related components in the dormant section. I think a component with
>> things for both SAX and DOM would be fine, and letting it grow
>> organically would also work well.
>
> Ok, but lets suggest another name like Commons XML. For example, this
> might be a good place for SAX -> StAX converters and stuff like that.
> No sense in restricting it to SAX by name.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Proposal: Commons SAX
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Mon, Dec 29, 2008 at 4:56 AM, Henri Yandell <fl...@gmail.com> wrote:
> I don't see why it's not a good fit for Commons. We've a few xml
> related components in the dormant section. I think a component with
> things for both SAX and DOM would be fine, and letting it grow
> organically would also work well.
Ok, but lets suggest another name like Commons XML. For example, this
might be a good place for SAX -> StAX converters and stuff like that.
No sense in restricting it to SAX by name.
Jochen
--
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone.
-- (Bjarne Stroustrup,
http://www.research.att.com/~bs/bs_faq.html#really-say-that
My guess: Nokia E50)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Proposal: Commons SAX
Posted by Henri Yandell <fl...@gmail.com>.
I don't see why it's not a good fit for Commons. We've a few xml
related components in the dormant section. I think a component with
things for both SAX and DOM would be fine, and letting it grow
organically would also work well.
Hen
On Wed, Dec 17, 2008 at 5:09 AM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> In the Apache Tika project [1] we use SAX quite a lot, and have
> written a set of quite useful general utility classes for SAX
> handling.
>
> For example, in org.apache.tika.sax [2] we have the following:
>
> * ContentHandlerDecorator - Convenient base class for writing
> ContentHandler decorators
> * EmbeddedContentHandler - Decorator that blocks startDocument() and
> endDocument() calls
> * TeeContentHandler - Forwards SAX events to multiple handlers
> * TextContentHandler - Decorator that blocks everything but character
> events (and start/endDocument)
> * WriteOutContentHandler - Writes the contents of all character events
> to a Writer
>
> In org.apache.tika.sax.xpath [3] we have a simple XPath subset
> implementation that supports streaming and filtering of SAX events. In
> other words, the implementation doesn't need a DOM tree to evaluate
> XPath statements.
>
> I believe this code would be useful also outside Tika, and I was
> thinking that it might perhaps make sense to create a Commons project
> for this. I also know of some SAX processing classes in Cocoon and
> Jackrabbit that could well be of interest to a wider audience.
>
> Do you think something like this would be interesting as a Commons
> project? Are there other similar efforts that I should know of? I
> looked at XML Commons in xml.apache.org, but it seems pretty dormant.
>
> [1] http://lucene.apache.org/tika/
> [2] http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/package-summary.html
> [3] http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/xpath/package-summary.html
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: Proposal: Commons SAX
Posted by Uwe Schindler <us...@pangaea.de>.
Don't forget ElementMappingContentHandler, its useful for others, too :)
Uwe
-----
UWE SCHINDLER
Webserver/Middleware Development
PANGAEA - Publishing Network for Geoscientific and Environmental Data
MARUM - University of Bremen
Room 2500, Leobener Str., D-28359 Bremen
Tel.: +49 421 218 65595
Fax: +49 421 218 65505
http://www.pangaea.de/
E-mail: uschindler@pangaea.de
> -----Original Message-----
> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> Sent: Wednesday, December 17, 2008 2:17 PM
> To: tika-dev@lucene.apache.org
> Subject: Fwd: Proposal: Commons SAX
>
> Hi,
>
> I think the SAX classes that we've come up in o.a.tika.sax would be
> useful also to other projects that don't otherwise depend on Tika, so
> I've contacted Apache Commons about the possibility of starting a
> "Commons SAX" component to make the code available to a wider
> audience. See below for the proposal.
>
> BR,
>
> Jukka Zitting
>
>
>
> ---------- Forwarded message ----------
> From: Jukka Zitting <ju...@gmail.com>
> Date: Wed, Dec 17, 2008 at 2:09 PM
> Subject: Proposal: Commons SAX
> To: Jakarta Commons Developers List <de...@commons.apache.org>
>
>
> Hi,
>
> In the Apache Tika project [1] we use SAX quite a lot, and have
> written a set of quite useful general utility classes for SAX
> handling.
>
> For example, in org.apache.tika.sax [2] we have the following:
>
> * ContentHandlerDecorator - Convenient base class for writing
> ContentHandler decorators
> * EmbeddedContentHandler - Decorator that blocks startDocument() and
> endDocument() calls
> * TeeContentHandler - Forwards SAX events to multiple handlers
> * TextContentHandler - Decorator that blocks everything but character
> events (and start/endDocument)
> * WriteOutContentHandler - Writes the contents of all character events
> to a Writer
>
> In org.apache.tika.sax.xpath [3] we have a simple XPath subset
> implementation that supports streaming and filtering of SAX events. In
> other words, the implementation doesn't need a DOM tree to evaluate
> XPath statements.
>
> I believe this code would be useful also outside Tika, and I was
> thinking that it might perhaps make sense to create a Commons project
> for this. I also know of some SAX processing classes in Cocoon and
> Jackrabbit that could well be of interest to a wider audience.
>
> Do you think something like this would be interesting as a Commons
> project? Are there other similar efforts that I should know of? I
> looked at XML Commons in xml.apache.org, but it seems pretty dormant.
>
> [1] http://lucene.apache.org/tika/
> [2] http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/package-
> summary.html
> [3]
> http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/xpath/package-
> summary.html
>
> BR,
>
> Jukka Zitting
Fwd: Proposal: Commons SAX
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
I think the SAX classes that we've come up in o.a.tika.sax would be
useful also to other projects that don't otherwise depend on Tika, so
I've contacted Apache Commons about the possibility of starting a
"Commons SAX" component to make the code available to a wider
audience. See below for the proposal.
BR,
Jukka Zitting
---------- Forwarded message ----------
From: Jukka Zitting <ju...@gmail.com>
Date: Wed, Dec 17, 2008 at 2:09 PM
Subject: Proposal: Commons SAX
To: Jakarta Commons Developers List <de...@commons.apache.org>
Hi,
In the Apache Tika project [1] we use SAX quite a lot, and have
written a set of quite useful general utility classes for SAX
handling.
For example, in org.apache.tika.sax [2] we have the following:
* ContentHandlerDecorator - Convenient base class for writing
ContentHandler decorators
* EmbeddedContentHandler - Decorator that blocks startDocument() and
endDocument() calls
* TeeContentHandler - Forwards SAX events to multiple handlers
* TextContentHandler - Decorator that blocks everything but character
events (and start/endDocument)
* WriteOutContentHandler - Writes the contents of all character events
to a Writer
In org.apache.tika.sax.xpath [3] we have a simple XPath subset
implementation that supports streaming and filtering of SAX events. In
other words, the implementation doesn't need a DOM tree to evaluate
XPath statements.
I believe this code would be useful also outside Tika, and I was
thinking that it might perhaps make sense to create a Commons project
for this. I also know of some SAX processing classes in Cocoon and
Jackrabbit that could well be of interest to a wider audience.
Do you think something like this would be interesting as a Commons
project? Are there other similar efforts that I should know of? I
looked at XML Commons in xml.apache.org, but it seems pretty dormant.
[1] http://lucene.apache.org/tika/
[2] http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/package-summary.html
[3] http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/xpath/package-summary.html
BR,
Jukka Zitting
Re: Fwd: Proposal: Commons SAX
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Feb 10, 2009 at 5:06 PM, Elliotte Harold <el...@metalab.unc.edu> wrote:
> I for one am having increasing trouble sorting out just what's where and
> worked on by whom at Apache.
It's a big place. :-)
> But as I said, I don't really understand the logic (if any) of how it's
> organized now, so please clean it up however you can with an eye
> toward how this looks to outsiders.
For now I just wanted to get started somewhere where I have commit
rights. The sandbox in Apache Commons is a good place in that respect,
as all Apache committers are welcome to work there.
Once we have something more concrete (i.e. useful working code) in
place it will be much easier to discuss where this library should be
developed as we'll know better who is interested in contributing and
using the library.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: Fwd: Proposal: Commons SAX
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Elliotte Harold <el...@metalab.unc.edu> wrote on 02/10/2009 11:06:16 AM:
> Jukka Zitting wrote:
>
> > You're right. If the code is to remain in Apache Commons (i.e. not
> > moved here to XML Commons), then we should probably rename it to
> > something like Commons JAXP.
>
> I for one am having increasing trouble sorting out just what's where and
> worked on by whom at Apache.
>
> Looking at it as an interested outsider, I really think there should be
> one XML Project which includes Xerces, Xalan, and XML Commons.
This is the opposite direction of where things are heading. If you haven't
noticed the XML project is being disbanded. Xerces has been out on its own
for a long time now. See all the discussion in the various ASF mailing list
archives as to why umbrella projects are being broken up. It's old ground
now.
> This proposal (which I still don't fully understand) belongs either in
XML
> Commons or perhaps in a separate subproject called XML Utilities. The
> latter would make sense if the purpose of Commons is only to bundle
> common libraries like DOM and JAXP. However if that's the case then the
> resolver might need to move out of Commons into its own subproject.
> Xerces and Xalan should not be separate projects, or at least should be
> presented to the world that way. Right now the external organization at
> Apache seems to reflect the internal developer organization way too
> closely. It's time to decouple them.
>
> But as I said, I don't really understand the logic (if any) of how it's
> organized now, so please clean it up however you can with an eye toward
> how this looks to outsiders.
>
> It's possible that once this gets rolling I might be able to make some
> significant contributions of already written code, but as is I can't
> explain to my manager what it is you're doing and I'm not all that sure
> myself. I know my day job has some general purpose utility code for
> working with JAXP and SAX and what not that we've vaguely considered
> open sourcing one of these days, but whether it fits this project or
> not, I can't yet say.
>
> --
> Elliotte Rusty Harold elharo@metalab.unc.edu
> Refactoring HTML Just Published!
> http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Re: Fwd: Proposal: Commons SAX
Posted by Elliotte Harold <el...@metalab.unc.edu>.
Jukka Zitting wrote:
> You're right. If the code is to remain in Apache Commons (i.e. not
> moved here to XML Commons), then we should probably rename it to
> something like Commons JAXP.
I for one am having increasing trouble sorting out just what's where and
worked on by whom at Apache.
Looking at it as an interested outsider, I really think there should be
one XML Project which includes Xerces, Xalan, and XML Commons. This
proposal (which I still don't fully understand) belongs either in XML
Commons or perhaps in a separate subproject called XML Utilities. The
latter would make sense if the purpose of Commons is only to bundle
common libraries like DOM and JAXP. However if that's the case then the
resolver might need to move out of Commons into its own subproject.
Xerces and Xalan should not be separate projects, or at least should be
presented to the world that way. Right now the external organization at
Apache seems to reflect the internal developer organization way too
closely. It's time to decouple them.
But as I said, I don't really understand the logic (if any) of how it's
organized now, so please clean it up however you can with an eye toward
how this looks to outsiders.
It's possible that once this gets rolling I might be able to make some
significant contributions of already written code, but as is I can't
explain to my manager what it is you're doing and I'm not all that sure
myself. I know my day job has some general purpose utility code for
working with JAXP and SAX and what not that we've vaguely considered
open sourcing one of these days, but whether it fits this project or
not, I can't yet say.
--
Elliotte Rusty Harold elharo@metalab.unc.edu
Refactoring HTML Just Published!
http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: Fwd: Proposal: Commons SAX
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Feb 10, 2009 at 3:39 PM, Michael Glavassevich
<mr...@ca.ibm.com> wrote:
> I do think the proposed name for this sandbox project may cause confusion.
> Commons XML vs. XML Commons.
You're right. If the code is to remain in Apache Commons (i.e. not
moved here to XML Commons), then we should probably rename it to
something like Commons JAXP.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: Fwd: Proposal: Commons SAX
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Elliotte Harold <el...@metalab.unc.edu> wrote on 02/10/2009 09:28:22 AM:
> Jukka Zitting wrote:
> > Hi,
> >
> > On Wed, Dec 31, 2008 at 2:43 PM, Jukka Zitting <jukka.
> zitting@gmail.com> wrote:
> >> FYI: It looks like there are similar plans also in Cocoon, and it was
> >> suggested that a Cocoon subproject might also be a good place for a
> >> utility library like the one I was proposing.
> >
> > To keep things moving I've started a Commons sandbox component in
> > https://svn.apache.org/repos/asf/commons/sandbox/xml/. See below for
> > the related project proposal I wrote.
> >
>
> How does this differe/integrate with Apache XML Commons?
>
> http://xml.apache.org/commons/
The developers interested in working on the utilities decided to do the
work in a sandbox first before working out where its ultimate home should
be. XML Commons is one of the possibilities.
I do think the proposed name for this sandbox project may cause confusion.
Commons XML vs. XML Commons. Ditto for the name of the Commons TLP given
all the other sub-projects around the ASF which have Commons in their name.
> --
> Elliotte Rusty Harold elharo@metalab.unc.edu
> Refactoring HTML Just Published!
> http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Re: Fwd: Proposal: Commons SAX
Posted by Elliotte Harold <el...@metalab.unc.edu>.
Jukka Zitting wrote:
> Hi,
>
> On Wed, Dec 31, 2008 at 2:43 PM, Jukka Zitting <ju...@gmail.com> wrote:
>> FYI: It looks like there are similar plans also in Cocoon, and it was
>> suggested that a Cocoon subproject might also be a good place for a
>> utility library like the one I was proposing.
>
> To keep things moving I've started a Commons sandbox component in
> https://svn.apache.org/repos/asf/commons/sandbox/xml/. See below for
> the related project proposal I wrote.
>
How does this differe/integrate with Apache XML Commons?
http://xml.apache.org/commons/
--
Elliotte Rusty Harold elharo@metalab.unc.edu
Refactoring HTML Just Published!
http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: Fwd: Proposal: Commons SAX
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Dec 31, 2008 at 2:43 PM, Jukka Zitting <ju...@gmail.com> wrote:
> FYI: It looks like there are similar plans also in Cocoon, and it was
> suggested that a Cocoon subproject might also be a good place for a
> utility library like the one I was proposing.
To keep things moving I've started a Commons sandbox component in
https://svn.apache.org/repos/asf/commons/sandbox/xml/. See below for
the related project proposal I wrote.
The idea for now is to just start putting together some usable code.
We can revisit the question of which project is the best place for
developing and maintaining the library once we know where there is
most interest to it.
BR,
Jukka Zitting
====================================
Proposal for the Commons XML Package
====================================
0. Rationale
------------
Many Apache projects have implemented utility classes for working with
XML documents and the Java API for XML Processing (JAXP) interfaces. These
classes can encapsulate years of experience with XML processing, but they
can be hard to find and reuse outside the originating project. It would be
beneficial to have a well maintained shared library of such code.
Various Apache projects like Xerces and Cocoon have been suggested as
appropriate places where such a shared library could be developed and
maintained. No clear consensus has however been reached on this matter.
For now the plan is to just start collecting initial code and interested
contributors in the Commons sandbox. We can revisit the question of the
eventual location of this codebase once it is clearer what code will be
included and who are most interested in developing and maintaining the code.
1. Scope of the Package
------------------------
The Commons XML package will contain utility code designed to make
working with JAXP easier. The goal is to work with the existing JAXP
infrastructure instead of trying to come up with an alternative.
1.5 Interaction With Other Packages
The Commons XML package will depend only on the Java 5 platform and the JAXP
interfaces included in it. No external dependencies or configuration files
will be used.
2. Initial Source of the Package
--------------------------------
The initial code of the Commmons XML package will be collected from
various Apache projects like Tika, Cocoon and Jackrabbit.
The code will be placed within the org.apache.commons.xml package.
Subpackages for specific types of code like SAX or DOM utilities will
be created as appropriate.
3. Required Commons Resources
-----------------------------
Version Control
The Commons XML codebase is located in the "xml" directory
inside the Commons Sandbox tree. The codebase can be found at:
https://svn.apache.org/repos/asf/commons/sandbox/xml/trunk/
Mailing List
Discussions about the Commons XML package will take place on the
dev@commons.apache.org mailing list. The subject lines of related
messages should prefixed with [xml].
Issue Tracker
No issue tracker will be set up for now. We can decide where and
how to track issues once the future location of the package becomes
clearer.
4. Initial Committers
---------------------
The proposal is currently being driven by Jukka Zitting, but any
Apache committer is welcome to join the effort.
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: Fwd: Proposal: Commons SAX
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
FYI: It looks like there are similar plans also in Cocoon, and it was
suggested that a Cocoon subproject might also be a good place for a
utility library like the one I was proposing.
On Sun, Dec 21, 2008 at 9:42 AM, Michael Glavassevich
<mr...@ca.ibm.com> wrote:
> "Jukka Zitting" <ju...@gmail.com> wrote on 12/19/2008 05:52:05 AM:
>> Have you seen the recent idea about the "federated commons" [1]?
>
> Nope, I haven't heard of this before. I just read the blog post but I'm not
> sure I got the gist of it, perhaps because of how late I read it, the length
> of the post (metaphors and all) and my general lack of familiarity with the
> Commons project. Does this imply much more than a "Commons federation"
> website which links to each XYZ Commons project, stating a few goals which
> all the commons projects share?
At the moment it's pretty much what we want to make of it. Until now
the federation idea has not been put to practice, but I'm actually
pursuing it now on two fronts: for this utility library and for a JCR
Commons subproject we're planning to start at Apache Jackrabbit.
As you say, I guess a good approach would be to have some set of
general guidelines (based on practices in Apache Commons) on how such
federated commons components should be organized and some section on
the commons.apache.org web site with pointers to those components.
> I hope the plan wouldn't include mashing all the mailing lists together.
+1
BR,
Jukka Zitting
Re: Fwd: Proposal: Commons SAX
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
FYI: It looks like there are similar plans also in Cocoon, and it was
suggested that a Cocoon subproject might also be a good place for a
utility library like the one I was proposing.
On Sun, Dec 21, 2008 at 9:42 AM, Michael Glavassevich
<mr...@ca.ibm.com> wrote:
> "Jukka Zitting" <ju...@gmail.com> wrote on 12/19/2008 05:52:05 AM:
>> Have you seen the recent idea about the "federated commons" [1]?
>
> Nope, I haven't heard of this before. I just read the blog post but I'm not
> sure I got the gist of it, perhaps because of how late I read it, the length
> of the post (metaphors and all) and my general lack of familiarity with the
> Commons project. Does this imply much more than a "Commons federation"
> website which links to each XYZ Commons project, stating a few goals which
> all the commons projects share?
At the moment it's pretty much what we want to make of it. Until now
the federation idea has not been put to practice, but I'm actually
pursuing it now on two fronts: for this utility library and for a JCR
Commons subproject we're planning to start at Apache Jackrabbit.
As you say, I guess a good approach would be to have some set of
general guidelines (based on practices in Apache Commons) on how such
federated commons components should be organized and some section on
the commons.apache.org web site with pointers to those components.
> I hope the plan wouldn't include mashing all the mailing lists together.
+1
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: Fwd: Proposal: Commons SAX
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Jukka,
"Jukka Zitting" <ju...@gmail.com> wrote on 12/19/2008 05:52:05 AM:
> Hi,
>
> On Fri, Dec 19, 2008 at 5:16 AM, Michael Glavassevich
> <mr...@ca.ibm.com> wrote:
> > It sounds like it might be a good match. I think XML Commons always
hoped to
> > add common XML utilities to the project.
>
> Cool!
>
> > I am curious though about what kind of community you were hoping would
build
> > around this code. You should know that XML Commons has fairly low
activity
> > [1] with only two components (XML Commons External [aka XML APIs] and
the
> > XML Commons Resolver) that are being maintained by a few committers.
>
> Community issues were most heavily on my mind when originally thinking
> of taking this to Apache Commons as they're good at handling these
> kinds of components where the related community is small and only
> sporadically active. But I'd be happy to do this also within Xerces
> (and it looks like Jeremias would too).
>
> Have you seen the recent idea about the "federated commons" [1]?
Nope, I haven't heard of this before. I just read the blog post but I'm not
sure I got the gist of it, perhaps because of how late I read it, the
length of the post (metaphors and all) and my general lack of familiarity
with the Commons project. Does this imply much more than a "Commons
federation" website which links to each XYZ Commons project, stating a few
goals which all the commons projects share? Perhaps something similar to
http://projects.apache.org/ (or part of this site)? And would this be
limited to Java projects only? Though all the existing XML Commons
components are written in Java, I imagine there might be a C++ version of
the resolver one day or possibility other utilities written in other
languages. The scope of the project always allowed for these to come in.
I hope the plan wouldn't include mashing all the mailing lists together. I
took a peek at the mailing list archives for Commons and saw that some
months have had 1000+ posts. That would be way too much noise in my in-box
for me to stay subscribed and paying attention for the few posts I'd
actually be interested in.
> That could be used to increase the visiblity of XML Commons while still
> keeping development within Xerces where I believe one finds the best
> XML experts at Apache.
>
> [1] http://blog.generationjava.com/roller/bayard/entry/the-open-and-
> federated-commons
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Re: Fwd: Proposal: Commons SAX
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Jukka,
"Jukka Zitting" <ju...@gmail.com> wrote on 12/19/2008 05:52:05 AM:
> Hi,
>
> On Fri, Dec 19, 2008 at 5:16 AM, Michael Glavassevich
> <mr...@ca.ibm.com> wrote:
> > It sounds like it might be a good match. I think XML Commons always
hoped to
> > add common XML utilities to the project.
>
> Cool!
>
> > I am curious though about what kind of community you were hoping would
build
> > around this code. You should know that XML Commons has fairly low
activity
> > [1] with only two components (XML Commons External [aka XML APIs] and
the
> > XML Commons Resolver) that are being maintained by a few committers.
>
> Community issues were most heavily on my mind when originally thinking
> of taking this to Apache Commons as they're good at handling these
> kinds of components where the related community is small and only
> sporadically active. But I'd be happy to do this also within Xerces
> (and it looks like Jeremias would too).
>
> Have you seen the recent idea about the "federated commons" [1]?
Nope, I haven't heard of this before. I just read the blog post but I'm not
sure I got the gist of it, perhaps because of how late I read it, the
length of the post (metaphors and all) and my general lack of familiarity
with the Commons project. Does this imply much more than a "Commons
federation" website which links to each XYZ Commons project, stating a few
goals which all the commons projects share? Perhaps something similar to
http://projects.apache.org/ (or part of this site)? And would this be
limited to Java projects only? Though all the existing XML Commons
components are written in Java, I imagine there might be a C++ version of
the resolver one day or possibility other utilities written in other
languages. The scope of the project always allowed for these to come in.
I hope the plan wouldn't include mashing all the mailing lists together. I
took a peek at the mailing list archives for Commons and saw that some
months have had 1000+ posts. That would be way too much noise in my in-box
for me to stay subscribed and paying attention for the few posts I'd
actually be interested in.
> That could be used to increase the visiblity of XML Commons while still
> keeping development within Xerces where I believe one finds the best
> XML experts at Apache.
>
> [1] http://blog.generationjava.com/roller/bayard/entry/the-open-and-
> federated-commons
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Re: Fwd: Proposal: Commons SAX
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Dec 19, 2008 at 5:16 AM, Michael Glavassevich
<mr...@ca.ibm.com> wrote:
> It sounds like it might be a good match. I think XML Commons always hoped to
> add common XML utilities to the project.
Cool!
> I am curious though about what kind of community you were hoping would build
> around this code. You should know that XML Commons has fairly low activity
> [1] with only two components (XML Commons External [aka XML APIs] and the
> XML Commons Resolver) that are being maintained by a few committers.
Community issues were most heavily on my mind when originally thinking
of taking this to Apache Commons as they're good at handling these
kinds of components where the related community is small and only
sporadically active. But I'd be happy to do this also within Xerces
(and it looks like Jeremias would too).
Have you seen the recent idea about the "federated commons" [1]? That
could be used to increase the visiblity of XML Commons while still
keeping development within Xerces where I believe one finds the best
XML experts at Apache.
[1] http://blog.generationjava.com/roller/bayard/entry/the-open-and-federated-commons
BR,
Jukka Zitting
Re: Proposal: Commons SAX
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Jeremias,
Jeremias Maerki <de...@jeremias-maerki.ch> wrote on 12/19/2008 02:21:31 AM:
> Hi Michael,
>
> basically you might see familiar names again, like me. ;-) See my
> initial response to Jukka's proposal on Apache Commons:
> http://markmail.org/message/uqlr5pcdda3nms52
>
> Anyway, I don't think we can get high hopes that this will result in a
> package with high contribution level. XML Commons would not suddenly
> start to buzz with activity (I could be wrong). After all this will we a
> consolidation of useful tools written elsewhere with hopefully some
> discussions to improve them by sharing ideas. But it could actually
> attract some attention which would be a good thing. I'm regularly
> writing SAX-based code (parsing and generating) so I'm really interested
> in this.
Cool.
It could also help if the XML Commons website got some TLC. To someone
browsing the front page of it may look like the project is dead, with stale
information about things which happened in 2002(?) and news about ApacheCon
US 2005. Was hoping this would all get renovated and relocated under
xerces.apache.org but even our TLP site still needs a lot of work. We had
discussed moving the Xerces websites over to Forrest [1][2] awhile back but
doesn't look like the ball ever got rolling. I'd still like to see that
happen.
> As you've seen with XML Commons Externals, XML Graphics proposed to add
> some additional XML APIs but after that not much happened. Still, that
> part is a very important part for XML Graphics as it means we have a
> good place for those and we still depend on them. I don't think it's
> necessarily a bad sign if not much happens. The resolver is a widely
> adopted tool. It seems to be good enough not to attract more developers.
I understand. It's hard to attract folks to components which are basically
complete. That's been one of the challenges for Xerces-J. I suspect most
folks are generally happy with what they're getting (e.g. the core XML
scanner is getting to the point where it is or is almost bug free) though
it's gotten better for attracting developers as we've started working on
new things like XML Schema 1.1 and StAX.
> I don't expect an XML Commons SAX to be much different once it's
> established. At least, since it's not a single component but a
> collection of utilities, it will have a better chance to get regular
> attention even if probably at a relatively low rate.
>
> The only strange thing is that I didn't make the connection to XML
> Commons when Jukka posted the proposal on Apache Commons. Still
> wondering about that. ;-)
[1] http://marc.info/?t=119258002500006&r=1&w=2
[2] http://marc.info/?t=119524098300001&r=1&w=2
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Re: Proposal: Commons SAX
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Jeremias,
Jeremias Maerki <de...@jeremias-maerki.ch> wrote on 12/19/2008 02:21:31 AM:
> Hi Michael,
>
> basically you might see familiar names again, like me. ;-) See my
> initial response to Jukka's proposal on Apache Commons:
> http://markmail.org/message/uqlr5pcdda3nms52
>
> Anyway, I don't think we can get high hopes that this will result in a
> package with high contribution level. XML Commons would not suddenly
> start to buzz with activity (I could be wrong). After all this will we a
> consolidation of useful tools written elsewhere with hopefully some
> discussions to improve them by sharing ideas. But it could actually
> attract some attention which would be a good thing. I'm regularly
> writing SAX-based code (parsing and generating) so I'm really interested
> in this.
Cool.
It could also help if the XML Commons website got some TLC. To someone
browsing the front page of it may look like the project is dead, with stale
information about things which happened in 2002(?) and news about ApacheCon
US 2005. Was hoping this would all get renovated and relocated under
xerces.apache.org but even our TLP site still needs a lot of work. We had
discussed moving the Xerces websites over to Forrest [1][2] awhile back but
doesn't look like the ball ever got rolling. I'd still like to see that
happen.
> As you've seen with XML Commons Externals, XML Graphics proposed to add
> some additional XML APIs but after that not much happened. Still, that
> part is a very important part for XML Graphics as it means we have a
> good place for those and we still depend on them. I don't think it's
> necessarily a bad sign if not much happens. The resolver is a widely
> adopted tool. It seems to be good enough not to attract more developers.
I understand. It's hard to attract folks to components which are basically
complete. That's been one of the challenges for Xerces-J. I suspect most
folks are generally happy with what they're getting (e.g. the core XML
scanner is getting to the point where it is or is almost bug free) though
it's gotten better for attracting developers as we've started working on
new things like XML Schema 1.1 and StAX.
> I don't expect an XML Commons SAX to be much different once it's
> established. At least, since it's not a single component but a
> collection of utilities, it will have a better chance to get regular
> attention even if probably at a relatively low rate.
>
> The only strange thing is that I didn't make the connection to XML
> Commons when Jukka posted the proposal on Apache Commons. Still
> wondering about that. ;-)
[1] http://marc.info/?t=119258002500006&r=1&w=2
[2] http://marc.info/?t=119524098300001&r=1&w=2
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Re: Proposal: Commons SAX
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hi Michael,
basically you might see familiar names again, like me. ;-) See my
initial response to Jukka's proposal on Apache Commons:
http://markmail.org/message/uqlr5pcdda3nms52
Anyway, I don't think we can get high hopes that this will result in a
package with high contribution level. XML Commons would not suddenly
start to buzz with activity (I could be wrong). After all this will we a
consolidation of useful tools written elsewhere with hopefully some
discussions to improve them by sharing ideas. But it could actually
attract some attention which would be a good thing. I'm regularly
writing SAX-based code (parsing and generating) so I'm really interested
in this.
As you've seen with XML Commons Externals, XML Graphics proposed to add
some additional XML APIs but after that not much happened. Still, that
part is a very important part for XML Graphics as it means we have a
good place for those and we still depend on them. I don't think it's
necessarily a bad sign if not much happens. The resolver is a widely
adopted tool. It seems to be good enough not to attract more developers.
I don't expect an XML Commons SAX to be much different once it's
established. At least, since it's not a single component but a
collection of utilities, it will have a better chance to get regular
attention even if probably at a relatively low rate.
The only strange thing is that I didn't make the connection to XML
Commons when Jukka posted the proposal on Apache Commons. Still
wondering about that. ;-)
On 19.12.2008 05:16:49 Michael Glavassevich wrote:
>
> Hi Jukka,
>
> It sounds like it might be a good match. I think XML Commons always hoped
> to add common XML utilities to the project.
>
> I am curious though about what kind of community you were hoping would
> build around this code. You should know that XML Commons has fairly low
> activity [1] with only two components (XML Commons External [aka XML APIs]
> and the XML Commons Resolver) that are being maintained by a few
> committers. We do update them occasionally. For example this summer we
> upgraded XML Commons External to JAXP 1.4 just prior to starting an
> implementation of the new APIs in Xerces. Otherwise things are usually
> fairly quiet.
>
> Thanks.
>
> [1] http://www.ohloh.net/p/xml-commons/contributors
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
> "Jukka Zitting" <ju...@gmail.com> wrote on 12/18/2008 08:14:21 AM:
>
> > Hi,
> >
> > See below for a proposal I made at the Apache Commons project. I was
> > pointed to the Xerces project as the current home of the XML Commons
> > subproject, so I wanted to check with you on your thoughts about the
> > matter. Would this (a library of SAX utilities) be a good match for
> > the existing XML Commons project?
> >
> > BR,
> >
> > Jukka Zitting
> >
> >
> > ---------- Forwarded message ----------
> > From: Jukka Zitting <ju...@gmail.com>
> > Date: Wed, Dec 17, 2008 at 2:09 PM
> > Subject: Proposal: Commons SAX
> > To: Jakarta Commons Developers List <de...@commons.apache.org>
> >
> >
> > Hi,
> >
> > In the Apache Tika project [1] we use SAX quite a lot, and have
> > written a set of quite useful general utility classes for SAX
> > handling.
> >
> > For example, in org.apache.tika.sax [2] we have the following:
> >
> > * ContentHandlerDecorator - Convenient base class for writing
> > ContentHandler decorators
> > * EmbeddedContentHandler - Decorator that blocks startDocument() and
> > endDocument() calls
> > * TeeContentHandler - Forwards SAX events to multiple handlers
> > * TextContentHandler - Decorator that blocks everything but character
> > events (and start/endDocument)
> > * WriteOutContentHandler - Writes the contents of all character events
> > to a Writer
> >
> > In org.apache.tika.sax.xpath [3] we have a simple XPath subset
> > implementation that supports streaming and filtering of SAX events. In
> > other words, the implementation doesn't need a DOM tree to evaluate
> > XPath statements.
> >
> > I believe this code would be useful also outside Tika, and I was
> > thinking that it might perhaps make sense to create a Commons project
> > for this. I also know of some SAX processing classes in Cocoon and
> > Jackrabbit that could well be of interest to a wider audience.
> >
> > Do you think something like this would be interesting as a Commons
> > project? Are there other similar efforts that I should know of? I
> > looked at XML Commons in xml.apache.org, but it seems pretty dormant.
> >
> > [1] http://lucene.apache.org/tika/
> > [2] http://lucene.apache.
> > org/tika/apidocs/org/apache/tika/sax/package-summary.html
> > [3] http://lucene.apache.
> > org/tika/apidocs/org/apache/tika/sax/xpath/package-summary.html
> >
> > BR,
> >
> > Jukka Zitting
> >
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: Fwd: Proposal: Commons SAX
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Dec 19, 2008 at 5:16 AM, Michael Glavassevich
<mr...@ca.ibm.com> wrote:
> It sounds like it might be a good match. I think XML Commons always hoped to
> add common XML utilities to the project.
Cool!
> I am curious though about what kind of community you were hoping would build
> around this code. You should know that XML Commons has fairly low activity
> [1] with only two components (XML Commons External [aka XML APIs] and the
> XML Commons Resolver) that are being maintained by a few committers.
Community issues were most heavily on my mind when originally thinking
of taking this to Apache Commons as they're good at handling these
kinds of components where the related community is small and only
sporadically active. But I'd be happy to do this also within Xerces
(and it looks like Jeremias would too).
Have you seen the recent idea about the "federated commons" [1]? That
could be used to increase the visiblity of XML Commons while still
keeping development within Xerces where I believe one finds the best
XML experts at Apache.
[1] http://blog.generationjava.com/roller/bayard/entry/the-open-and-federated-commons
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: Proposal: Commons SAX
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hi Michael,
basically you might see familiar names again, like me. ;-) See my
initial response to Jukka's proposal on Apache Commons:
http://markmail.org/message/uqlr5pcdda3nms52
Anyway, I don't think we can get high hopes that this will result in a
package with high contribution level. XML Commons would not suddenly
start to buzz with activity (I could be wrong). After all this will we a
consolidation of useful tools written elsewhere with hopefully some
discussions to improve them by sharing ideas. But it could actually
attract some attention which would be a good thing. I'm regularly
writing SAX-based code (parsing and generating) so I'm really interested
in this.
As you've seen with XML Commons Externals, XML Graphics proposed to add
some additional XML APIs but after that not much happened. Still, that
part is a very important part for XML Graphics as it means we have a
good place for those and we still depend on them. I don't think it's
necessarily a bad sign if not much happens. The resolver is a widely
adopted tool. It seems to be good enough not to attract more developers.
I don't expect an XML Commons SAX to be much different once it's
established. At least, since it's not a single component but a
collection of utilities, it will have a better chance to get regular
attention even if probably at a relatively low rate.
The only strange thing is that I didn't make the connection to XML
Commons when Jukka posted the proposal on Apache Commons. Still
wondering about that. ;-)
On 19.12.2008 05:16:49 Michael Glavassevich wrote:
>
> Hi Jukka,
>
> It sounds like it might be a good match. I think XML Commons always hoped
> to add common XML utilities to the project.
>
> I am curious though about what kind of community you were hoping would
> build around this code. You should know that XML Commons has fairly low
> activity [1] with only two components (XML Commons External [aka XML APIs]
> and the XML Commons Resolver) that are being maintained by a few
> committers. We do update them occasionally. For example this summer we
> upgraded XML Commons External to JAXP 1.4 just prior to starting an
> implementation of the new APIs in Xerces. Otherwise things are usually
> fairly quiet.
>
> Thanks.
>
> [1] http://www.ohloh.net/p/xml-commons/contributors
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
> "Jukka Zitting" <ju...@gmail.com> wrote on 12/18/2008 08:14:21 AM:
>
> > Hi,
> >
> > See below for a proposal I made at the Apache Commons project. I was
> > pointed to the Xerces project as the current home of the XML Commons
> > subproject, so I wanted to check with you on your thoughts about the
> > matter. Would this (a library of SAX utilities) be a good match for
> > the existing XML Commons project?
> >
> > BR,
> >
> > Jukka Zitting
> >
> >
> > ---------- Forwarded message ----------
> > From: Jukka Zitting <ju...@gmail.com>
> > Date: Wed, Dec 17, 2008 at 2:09 PM
> > Subject: Proposal: Commons SAX
> > To: Jakarta Commons Developers List <de...@commons.apache.org>
> >
> >
> > Hi,
> >
> > In the Apache Tika project [1] we use SAX quite a lot, and have
> > written a set of quite useful general utility classes for SAX
> > handling.
> >
> > For example, in org.apache.tika.sax [2] we have the following:
> >
> > * ContentHandlerDecorator - Convenient base class for writing
> > ContentHandler decorators
> > * EmbeddedContentHandler - Decorator that blocks startDocument() and
> > endDocument() calls
> > * TeeContentHandler - Forwards SAX events to multiple handlers
> > * TextContentHandler - Decorator that blocks everything but character
> > events (and start/endDocument)
> > * WriteOutContentHandler - Writes the contents of all character events
> > to a Writer
> >
> > In org.apache.tika.sax.xpath [3] we have a simple XPath subset
> > implementation that supports streaming and filtering of SAX events. In
> > other words, the implementation doesn't need a DOM tree to evaluate
> > XPath statements.
> >
> > I believe this code would be useful also outside Tika, and I was
> > thinking that it might perhaps make sense to create a Commons project
> > for this. I also know of some SAX processing classes in Cocoon and
> > Jackrabbit that could well be of interest to a wider audience.
> >
> > Do you think something like this would be interesting as a Commons
> > project? Are there other similar efforts that I should know of? I
> > looked at XML Commons in xml.apache.org, but it seems pretty dormant.
> >
> > [1] http://lucene.apache.org/tika/
> > [2] http://lucene.apache.
> > org/tika/apidocs/org/apache/tika/sax/package-summary.html
> > [3] http://lucene.apache.
> > org/tika/apidocs/org/apache/tika/sax/xpath/package-summary.html
> >
> > BR,
> >
> > Jukka Zitting
> >
Jeremias Maerki
Re: Fwd: Proposal: Commons SAX
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Jukka,
It sounds like it might be a good match. I think XML Commons always hoped
to add common XML utilities to the project.
I am curious though about what kind of community you were hoping would
build around this code. You should know that XML Commons has fairly low
activity [1] with only two components (XML Commons External [aka XML APIs]
and the XML Commons Resolver) that are being maintained by a few
committers. We do update them occasionally. For example this summer we
upgraded XML Commons External to JAXP 1.4 just prior to starting an
implementation of the new APIs in Xerces. Otherwise things are usually
fairly quiet.
Thanks.
[1] http://www.ohloh.net/p/xml-commons/contributors
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
"Jukka Zitting" <ju...@gmail.com> wrote on 12/18/2008 08:14:21 AM:
> Hi,
>
> See below for a proposal I made at the Apache Commons project. I was
> pointed to the Xerces project as the current home of the XML Commons
> subproject, so I wanted to check with you on your thoughts about the
> matter. Would this (a library of SAX utilities) be a good match for
> the existing XML Commons project?
>
> BR,
>
> Jukka Zitting
>
>
> ---------- Forwarded message ----------
> From: Jukka Zitting <ju...@gmail.com>
> Date: Wed, Dec 17, 2008 at 2:09 PM
> Subject: Proposal: Commons SAX
> To: Jakarta Commons Developers List <de...@commons.apache.org>
>
>
> Hi,
>
> In the Apache Tika project [1] we use SAX quite a lot, and have
> written a set of quite useful general utility classes for SAX
> handling.
>
> For example, in org.apache.tika.sax [2] we have the following:
>
> * ContentHandlerDecorator - Convenient base class for writing
> ContentHandler decorators
> * EmbeddedContentHandler - Decorator that blocks startDocument() and
> endDocument() calls
> * TeeContentHandler - Forwards SAX events to multiple handlers
> * TextContentHandler - Decorator that blocks everything but character
> events (and start/endDocument)
> * WriteOutContentHandler - Writes the contents of all character events
> to a Writer
>
> In org.apache.tika.sax.xpath [3] we have a simple XPath subset
> implementation that supports streaming and filtering of SAX events. In
> other words, the implementation doesn't need a DOM tree to evaluate
> XPath statements.
>
> I believe this code would be useful also outside Tika, and I was
> thinking that it might perhaps make sense to create a Commons project
> for this. I also know of some SAX processing classes in Cocoon and
> Jackrabbit that could well be of interest to a wider audience.
>
> Do you think something like this would be interesting as a Commons
> project? Are there other similar efforts that I should know of? I
> looked at XML Commons in xml.apache.org, but it seems pretty dormant.
>
> [1] http://lucene.apache.org/tika/
> [2] http://lucene.apache.
> org/tika/apidocs/org/apache/tika/sax/package-summary.html
> [3] http://lucene.apache.
> org/tika/apidocs/org/apache/tika/sax/xpath/package-summary.html
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: Fwd: Proposal: Commons SAX
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Jukka,
It sounds like it might be a good match. I think XML Commons always hoped
to add common XML utilities to the project.
I am curious though about what kind of community you were hoping would
build around this code. You should know that XML Commons has fairly low
activity [1] with only two components (XML Commons External [aka XML APIs]
and the XML Commons Resolver) that are being maintained by a few
committers. We do update them occasionally. For example this summer we
upgraded XML Commons External to JAXP 1.4 just prior to starting an
implementation of the new APIs in Xerces. Otherwise things are usually
fairly quiet.
Thanks.
[1] http://www.ohloh.net/p/xml-commons/contributors
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
"Jukka Zitting" <ju...@gmail.com> wrote on 12/18/2008 08:14:21 AM:
> Hi,
>
> See below for a proposal I made at the Apache Commons project. I was
> pointed to the Xerces project as the current home of the XML Commons
> subproject, so I wanted to check with you on your thoughts about the
> matter. Would this (a library of SAX utilities) be a good match for
> the existing XML Commons project?
>
> BR,
>
> Jukka Zitting
>
>
> ---------- Forwarded message ----------
> From: Jukka Zitting <ju...@gmail.com>
> Date: Wed, Dec 17, 2008 at 2:09 PM
> Subject: Proposal: Commons SAX
> To: Jakarta Commons Developers List <de...@commons.apache.org>
>
>
> Hi,
>
> In the Apache Tika project [1] we use SAX quite a lot, and have
> written a set of quite useful general utility classes for SAX
> handling.
>
> For example, in org.apache.tika.sax [2] we have the following:
>
> * ContentHandlerDecorator - Convenient base class for writing
> ContentHandler decorators
> * EmbeddedContentHandler - Decorator that blocks startDocument() and
> endDocument() calls
> * TeeContentHandler - Forwards SAX events to multiple handlers
> * TextContentHandler - Decorator that blocks everything but character
> events (and start/endDocument)
> * WriteOutContentHandler - Writes the contents of all character events
> to a Writer
>
> In org.apache.tika.sax.xpath [3] we have a simple XPath subset
> implementation that supports streaming and filtering of SAX events. In
> other words, the implementation doesn't need a DOM tree to evaluate
> XPath statements.
>
> I believe this code would be useful also outside Tika, and I was
> thinking that it might perhaps make sense to create a Commons project
> for this. I also know of some SAX processing classes in Cocoon and
> Jackrabbit that could well be of interest to a wider audience.
>
> Do you think something like this would be interesting as a Commons
> project? Are there other similar efforts that I should know of? I
> looked at XML Commons in xml.apache.org, but it seems pretty dormant.
>
> [1] http://lucene.apache.org/tika/
> [2] http://lucene.apache.
> org/tika/apidocs/org/apache/tika/sax/package-summary.html
> [3] http://lucene.apache.
> org/tika/apidocs/org/apache/tika/sax/xpath/package-summary.html
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
Fwd: Proposal: Commons SAX
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
See below for a proposal I made at the Apache Commons project. I was
pointed to the Xerces project as the current home of the XML Commons
subproject, so I wanted to check with you on your thoughts about the
matter. Would this (a library of SAX utilities) be a good match for
the existing XML Commons project?
BR,
Jukka Zitting
---------- Forwarded message ----------
From: Jukka Zitting <ju...@gmail.com>
Date: Wed, Dec 17, 2008 at 2:09 PM
Subject: Proposal: Commons SAX
To: Jakarta Commons Developers List <de...@commons.apache.org>
Hi,
In the Apache Tika project [1] we use SAX quite a lot, and have
written a set of quite useful general utility classes for SAX
handling.
For example, in org.apache.tika.sax [2] we have the following:
* ContentHandlerDecorator - Convenient base class for writing
ContentHandler decorators
* EmbeddedContentHandler - Decorator that blocks startDocument() and
endDocument() calls
* TeeContentHandler - Forwards SAX events to multiple handlers
* TextContentHandler - Decorator that blocks everything but character
events (and start/endDocument)
* WriteOutContentHandler - Writes the contents of all character events
to a Writer
In org.apache.tika.sax.xpath [3] we have a simple XPath subset
implementation that supports streaming and filtering of SAX events. In
other words, the implementation doesn't need a DOM tree to evaluate
XPath statements.
I believe this code would be useful also outside Tika, and I was
thinking that it might perhaps make sense to create a Commons project
for this. I also know of some SAX processing classes in Cocoon and
Jackrabbit that could well be of interest to a wider audience.
Do you think something like this would be interesting as a Commons
project? Are there other similar efforts that I should know of? I
looked at XML Commons in xml.apache.org, but it seems pretty dormant.
[1] http://lucene.apache.org/tika/
[2] http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/package-summary.html
[3] http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/xpath/package-summary.html
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: Proposal: Commons SAX
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
FOP basically does all its XML parsing based on SAX. I don't see too
much overlap right now (without looking more closely). But maybe someone
can see something worth copying/moving in such a Commons SAX. A
colleague of mine had to implement something like a TeeContentHandler a
few weeks ago. So I guess there are use cases for things like that.
Here's a link to the SAX utility classes we have in FOP if anyone is
interested:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/util/
Relevant classes:
ContentHandlerFactory (used for handling embedded non-FO documents)
ContentHandlerFactoryRegistry
DOMBuilderContentHandlerFactory
DelegatingContentHandler
DOM2SAX (adapted from Xalan)
That was mostly the parsing side, but generating XML by generating SAX
events can also be very interesting and most of all damn fast and
versatile. Pure SAX method calls for generating XML are very verbose and
in many cases unnecessary. FOP's example code contains something I wrote
a long time ago.
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/tools/
I'm doing that differently today but I'm still not 100% happy. I've
written some new code in a dev branch I'm currently working in:
http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_AreaTreeNewDesign/src/java/org/apache/fop/util/
Relevant classes:
GenerationHelperContentHandler
XMLConstants
XMLUtil
Example using the above classes:
http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_AreaTreeNewDesign/src/sandbox/org/apache/fop/render/svg/SVGPainter.java?view=markup
In XML Graphics Commons, there's the interface XMLizable:
http://svn.apache.org/viewvc/xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/util/XMLizable.java?view=markup
which I've used a number of times. Basically, I've stolen that from
Excalibur/Cocoon:
http://excalibur.apache.org/apidocs/org/apache/excalibur/xml/sax/XMLizable.html
Says by itself that this is obviously useful.
Another handy utility is javax.xml.namespace.QName which is found
starting in Java 1.5. Since XML Graphics is still on Java 1.4 I've
written a similar class:
http://svn.apache.org/viewvc/xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/util/QName.java?view=markup
So, I'm just listing what comes to my mind. No idea what is useful. At
any rate, the Commons SAX idea is a good one IMO. I'd be happy to help
out depending on the scope (i.e. for what there is room).
On 17.12.2008 14:09:00 Jukka Zitting wrote:
> Hi,
>
> In the Apache Tika project [1] we use SAX quite a lot, and have
> written a set of quite useful general utility classes for SAX
> handling.
>
> For example, in org.apache.tika.sax [2] we have the following:
>
> * ContentHandlerDecorator - Convenient base class for writing
> ContentHandler decorators
> * EmbeddedContentHandler - Decorator that blocks startDocument() and
> endDocument() calls
> * TeeContentHandler - Forwards SAX events to multiple handlers
> * TextContentHandler - Decorator that blocks everything but character
> events (and start/endDocument)
> * WriteOutContentHandler - Writes the contents of all character events
> to a Writer
>
> In org.apache.tika.sax.xpath [3] we have a simple XPath subset
> implementation that supports streaming and filtering of SAX events. In
> other words, the implementation doesn't need a DOM tree to evaluate
> XPath statements.
>
> I believe this code would be useful also outside Tika, and I was
> thinking that it might perhaps make sense to create a Commons project
> for this. I also know of some SAX processing classes in Cocoon and
> Jackrabbit that could well be of interest to a wider audience.
>
> Do you think something like this would be interesting as a Commons
> project? Are there other similar efforts that I should know of? I
> looked at XML Commons in xml.apache.org, but it seems pretty dormant.
>
> [1] http://lucene.apache.org/tika/
> [2] http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/package-summary.html
> [3] http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/xpath/package-summary.html
>
> BR,
>
> Jukka Zitting
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org