Re: Xerces Sub-Projects (was "How to start writing a non-blockingSAX parser")

[Aleksander Slominski <as...@cs.indiana.edu>]

"Theodore W. Leung" wrote:

> > > I would be interested in seeing this make it into Xerces2, perhaps
> > > initially as a sample of how to use XNI.   I'd be willing to do commits
> > > / bug fixes to make this happen.
> >
> > If it's just to be included as a sample, I'd just as well
> > keep it hosted separately and point to it from the XNI Manual.
> > There seems to be a stigma among people that "sample" code is
> > not production ready.
>
> Then lets find a way to get all of this stuff into subprojects

that would allow for users of xerces2 to quickly get module they
want ot use just by getting xerces 2 distribution instead of many
separate modules (if xerces 2 is split into modules ...)

> > > It seems to me that NekoHTML could be treated the same way.  In fact
> > > that last message that I read on Neko talked about making it a
> > > subproject.  Has something changed?
> >
> > Nothing's really changed but I was looking at the Jakarta
> > guidelines for new projects. A lot of it makes sense to me
> > and since there really isn't any "community" around NekoHTML
> > I'm stuck in a quasi-state between wanting it added to Xerces
> > and not minding if it's kept separate.
>
> I guess another way that we could handle it would be to place it
> xml-commons -- Jakarta uses their commons for much broader things than
> we do.
>
> Personally, I think that Neko and Alek's pull parser should be tied to
> Xerces.  People have asked over and over again for HTML capability via
> Xerces, so I think that we ought to get Neko into a subproject.  Since
> there is a JSR for Pull parsing, I think that we should start some work
> to support a pull style API, and give some feedback to the JSR process.

xerces has very  good exposure with xml developers and such feedback
would be certainly very valuable!

XMLPULL API is intentionally simple to make it easy to use and
to create both small implementations that are limited  but well suited
for J2ME but as well allow for implementations that
are full featured (such as i think eventually xni2xmlpull will be by trying to
leverage xerces2). XMLPULL API  was developed evolutionally and is
result of merging kXML and XPP2 and is intended to work easily
fromJ 2ME to J2EE environments. JSR 173 is different as it is targeted
for J2SE Java platform (so can take full advantage of it)
and has more broad API plans including support for reading, representing
XML as events and writing XML .

thanks,

alek



---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org