You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by "Theodore W. Leung" <tw...@sauria.com> on 2002/05/03 21:21:44 UTC
Re: Xerces Sub-Projects (was "How to start writing a non-blocking
SAX parser")
On Thu, 2002-05-02 at 08:08, Andy Clark wrote:
> [That thread was getting a bit too deep. ;)]
>
> Ted Leung wrote:
> > > projects that are built on (or using) Xerces. This is the
> > > direction that my NekoHTML parser seems to be leaning as
> > > well.
> >
> > 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
> > 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.
Both of these projects are related to Xerces, so the Xerces committers
should be the ones to decide whether to take them in. You are already
a part of the Xerces community, so I don't really see a problem there.
Regardless of how Neko appears (subproject / separately hosted), I
definitely view it as having sprung from the Xerces family tree -- it's
not like it works on top of Crimson or Expat.
> Of course, as all things in Open Source Land, the mob rules.
> So if everyone still wants it to go forward for inclusion in
> the Xerces codebase, let's do it. But let's figure out all of
> the sub-project details first (e.g. HTML and WML DOMs; the
> serializers; as well as future donations).
Let's figure out how we want to do a modular xerces then.
> --
> Andy Clark * andyc@apache.org
>
> ---------------------------------------------------------------------
> In case of troubles, e-mail: webmaster@xml.apache.org
> To unsubscribe, e-mail: general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: Xerces Sub-Projects (was "How to start writing a non-blockingSAX
parser")
Posted by 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
---------------------------------------------------------------------
In case of troubles, e-mail: webmaster@xml.apache.org
To unsubscribe, e-mail: general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org
Re: Xerces Sub-Projects (was "How to start writing a non-blockingSAX
parser")
Posted by 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