Subjects
Home
VOTE Move XML Commons to Xerces
Commented: (XERCESJ 589) Bug with pattern restriction on long strings
: Xerces J 2 8 1 Release on Wednesday, September 13th
: Xerces J 2 9 0 Release on Wednesday, November 22nd
Commented: (XERCESJ 1066) Restriction+choice+substitutionGroup error
Commented: (XERCESJ 1178) Error getting prefix for an attribute with no n
Updated: (XERCESJ 1244) XMLSchemaValidator does not contribute element 's
Some consideration about the xerces DOM implementation
Updated: (XERCESJ 1066) Restriction+choice+substitutionGroup error
Commented: (XERCESJ 1227) Poor performance / OutOfMemoryError for sequenc
retain exception stack traces
Updated: (XERCESJ 1193) NPE or hang when parsing using the "continue afte
Future of NekoHTML
Commented: (XERCESJ 1203) NPE in XMLDTDProcessor
DOM Level 3 APIs for Xalan J and a new Xalan release (2 7 1)
: xml commons external 1 3 04 Release on Wednesday, November 22nd
Commented: (XERCESJ 1247) Incorrect location information on SAX when usin
XInclude exceptions how to mirror Xerces J functionality into Xerces C++?
First proposal on SoC project "Add support for the StAX (JSR 173) cursor API
: xml commons resolver 1 2 Release on Wednesday, November 22nd
Typo in RangeToken java Please check
Validator features
java lang ClassCastException when adopting Node
using the org apache xerces impl xs identity package
Updated: (XERCESJ 1257) buffer overflow in UTF8Reader for characters out
Problem with ref attributes and schema validation
Updated: (XERCESJ 122) XMLSchemaValidator does not contribute element 's d
Performance problem under load Xerces with Weblogic 9 x
remove ignored memory allocation
Commented: (XERCESJ 1177) SAXXMLStreamReader doesn 't always report namesp
Commented: (XERCESJ 977) Null pointer exception during DOM parsing
Commented: (XERCESJ 1197) Code cleanup for org apache xml serialize
Commented: (XERCESJ 1201) Initial contribution for StAX Event API
Updated: (XERCESJ 1061) Regex "$ " and "^ " characters treated as special c
Commented: (XERCESJ 1199) SAXXMLStreamReader should attempt to register a
Commented: (XERCESJ 1061) Regex "$ " and "^ " characters treated as special
Updated: (XERCESJ 589) Bug with pattern restriction on long strings
StackOverflow
xerces Range unnecessarily not garbage collectable if not detached
Updated: (XERCESJ 1178) Error getting prefix for an attribute with no nam
Bug in xs:redefine
Commented: (XERCESJ 1204) Can not set XMLEntityResolver for LSParser
Updated: (XERCESJ 1253) Prototype for SoC2007 project "Add support for th
Updated: (XERCESJ 1259) Add SteamFilter Function to SoC2007 project "Add
Assigned: (XERCESJ 444) SAXException thrown by EntityResolver is reported
Google Summer of Code 2007
Xerces J and XInclude relative path issue
Assigned: (XERCESJ 206) Stack overflow when using a schema validation
Commented: (XERCESJ 1215) Restrictions involving two levels of substituti
Closed: (XERCESJ 1203) NPE in XMLDTDProcessor
non overriding equals methoda
Resolved: (XERCESJ 1079) invalid value returned for TOTALDIGITS facet in
Xerces AS3 port
Updated: (XERCESJ 325) Regular Expression; Pattern "| " clause order de
Updated: (XERCESJ 1196) Javadoc generation fails on Java SE 5 0
Closed: (XERCESJ 1202) DTD validation on XIncluded documents when the sch
Created: (XERCESJ 1124) Nonspecific schema error message
a bug in xerces
Updated: (XERCESJ 1201) Initial contribution for StAX Event API
Closed: (XERCESJ 1254) Empty uris in targetNamespace attribute not report
Links
Home
Oracle database error code
 
Search:  
Power your search with and, or, +, -, or "some phrase" operators.
Future of NekoHTML

Future of NekoHTML

2007-04-20       - By Neil Graham
Reply:     1     2     3     4  

Hi Andy,

Just wanted to make sure you're aware of the new Apache Labs project [*].
It's designed to be a place where committers can put interesting code
where the goal isn't necessarily to develop a community.  So you get SVN
infrastructural support etc.

After Xerces-J's experience with the WML DOM and the HTML DOM, I would
venture to guess there would be a certain amount of unease at the prospect
of accepting a code base without an active developer community.  Perhaps
this is the source (aside from Apache practice these days that is) for the
suggestion that the Incubator would be the right place to start.  But
since I'm even less active than you are these days :(, definitely for
others to decide!

Cheers,
Neil
[*]:  http://labs.apache.org/
Neil Graham
Manager, C++ Compiler Front-End and Runtime Development
IBM Toronto Lab
Phone:  905-413-3519, T/L 969-3519
E-mail:  neilg@(protected)





Andy Clark <andyc@(protected)>
04/19/07 09:26 PM
Please respond to
j-dev@(protected)


To
Xerces-J Dev <j-dev@(protected)>, Xerces-J Users
<j-users@(protected)>
cc

Subject
Future of NekoHTML






Hello, Xerces-J! It has been a long time since I've
been active in the Xerces community, or even posted to
this mailing list. The primary reason being that I just
don't have the free time I did in years past. New jobs
and new interests have kept me busy and prevented me
from working consistently on the NekoHTML[1] project.

However, during that time, interest in NekoHTML has
remained and many users have inquired about the future
of the code. Since I don't have as much time to work on
the project as before, I am at a crossroads wondering
what to do with the project.

It has always been my wish to donate the code to the
Xerces-J project so that it's an integrated part of the
parser project and is available to all users of Xerces.
In the past, when I suggested donating the code it was
requested that I go through the Incubator process.

Putting aside the fact that taking code through the
Incubator process is a long, laborious process, I never
felt that the Incubator was an appropriate place for
NekoHTML for a number of reasons. First, the purpose of
the Incubator has been to ensure that an incoming project
develops a strong community made up of not only of the
original developers but also from members of the Apache
community. However, NekoHTML is the work of a single
person.

Second, the NekoHTML parser is a self-contained and
complete set of code. No additional work needs to be
done and therefore no community needed to develop it
further. Aside from minor bug fixes and the occasional
updates needed for API changes in the Xerces Native
Interface (XNI), NekoHTML has been solid and in use by
many projects and products since its inception in 2002.

So the question remains: what do I do with the code
moving forward?

My preference is to have it adopted by the Xerces-J
project. Very little effort would be required to
integrate it into the project and minimal resources
would be needed to keep it in sync with changes to
Xerces-J in the future. But the benefit to users
would be tremendous. They would have the ability to
parse HTML documents using the same APIs and tools
that they use for parsing XML documents today. And
since it's built on XNI, it's uniquely integrated
with the Xerces-J parser and its infrastructure.

Regardless of my personal preference, I leave it up
to the community to decide whether it becomes part of
the Xerces-J project. If you feel that it's not the
right place for the code, that's fine. In that case,
I'll start a project at SourceForge so that NekoHTML
has a permanent home for future development.

Thoughts?

[1] http://people.apache.org/~andyc/neko/doc/html/

--
Andy Clark * andyc@(protected)

---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@(protected)
For additional commands, e-mail: j-dev-help@(protected)




---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@(protected)
For additional commands, e-mail: j-dev-help@(protected)