Project Mission
Mission/Charter
The most current copy of our charter can always be found at http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt; however a recent copy is included herein.
1 INTRODUCTION
==============
1.1 xml.apache.org is a collaborative software development project
dedicated to providing robust, full-featured, commercial-quality, and
freely available XML support on a wide variety of platforms. This
project is managed in cooperation with various individuals worldwide
(both independent and company-affiliated experts), who use the
Internet to communicate, plan, and develop XML software and related
documentation.
1.2 This charter briefly describes the mission, history, organization, and
processes of the project.
2 MISSION
=========
2.1 xml.apache.org exists to promote the use of XML. We view XML as a
compelling paradigm that structures data as information, thereby
facilitating the exchange, transformation, and presentation of
knowledge. The ability to transform raw data into usable information
has great potential to improve the functionality and use of
information systems. We intend to build freely available XML
processing components in order to engender such improvements.
2.2 xml.apache.org defines a set of components that exchange or deal
with XML information sets. Where appropriate, these components plug
into each other using standard APIs (formal, de facto, or proposed).
The components must be high performance, reliable, and easy to use.
Where inter-related, the components must be part of an underlying
architectural orchestration that will allow them to work together
without major negotiations or breakage.
2.3 We believe that the best way to define this XML information exchange
architecture is by having both individuals and corporations
collaborate on the best possible infrastructure, APIs, code, testing,
and release cycles. Components must be vendor neutral and usable as
core components for all.
2.4 In order to achieve a coherent architecture between xml.apache.org
components and other components and applications, standards (formal or
de facto) will be used as much as possible for both protocols and
APIs. Where appropriate, experiences and lessons learned will be fed
back to standards bodies in an effort to assist in the development of
those standards. We will also encourage the innovation of new
protocols, APIs, and components in order to seed new concepts not
yet defined by standards.
3 HISTORY
=========
3.1 This project was established under the direction of the newly-formed
Apache Software Foundation in August 1999 to facilitate joint
open-source development.
4 TERMS
=======
4.1 The ASF Board. The management board of the Apache Software
Foundation.
4.2 The Project. The Apache XML Project, referred to in this
document as "xml.apache.org" or "the xml.apache.org project".
4.3 Subproject. xml.apache.org is comprised of a number of subprojects;
a subproject is responsible for a component or application whose scope
is well defined.
4.4 Contributor. Anyone who makes a contribution to the development
of the xml.apache.org project or a subproject.
4.5 Committer. Each subproject has a set of committers. Committers
are contributors who have read/write access to the source code
repository.
5 THE PROJECT MANAGEMENT COMMITTEE
==================================
5.1 The xml.apache.org project is managed by a core group of
contributors known as the Project Management Committee [PMC],
with representation from all sub-projects.
5.2 The activities of the PMC are coordinated by the Chairperson,
who is an officer of corporation and reports to the Apache
Board. The Chairperson will, on the request of the Apache Board,
provide reports to the Board on issues related to the running of
the xml.apache.org project.
5.3 The PMC has the following responsibilities:
a) Accepting new subproject proposals, formally submitting these
proposals for xml.apache.org committer vote, and creating the
subproject (see SUBPROJECTS below). This is done in collaboration
with the Incubator (see http://incubator.apache.org).
b) Facilitating code or other donations by individuals or companies,
in collaboration with the Incubator.
c) Resolving license issues and other legal issues in conjunction with
the ASF board.
d) Ensuring that administrative and infrastructure work is completed.
e) Facilitating relationships among projects and subprojects.
f) Facilitating relationships between xml.apache.org and the external
world.
g) Overseeing xml.apache.org to ensure that the mission defined in
this document is being fulfilled.
h) Resolving conflicts within the project.
i) Reporting to the ASF board (through the Chair) on the progress
of the project.
5.4 Every 12 months, (or as required by the Board or PMC) each subproject
of xml.apache.org will nominate 1-2 individuals to represent them on the
PMC. To become a sub-project's representative on the PMC, an individual
must be nominated by a contributor, unanimously approved by all PMC
members, and approved by a two-thirds majority of the sub-project's
active committers. In most cases, developers will have actively
contributed to development for at least six months before being
considered for membership on the PMC.
5.5 In cases where the sub-project is unable to directly provide a
representative on the PMC, another member of the PMC will be required
to represent that sub-project on the PMC. This will be strongly
discouraged. It is preferable that all sub-projects have direct
representation on the PMC.
5.6 Once the PMC selection process has completed, the PMC will provide
a recommendation to the Apache Board for the position of Chairperson
of the PMC.
5.7 This recommendation will be made on the basis of an election held
within the PMC. The election will be performed using a simple
majority vote of PMC members.
5.8 Upon agreement by the Apache Board, the recommended Chairperson will,
if they are not already, be appointed an officer of the corporation.
See http://www.apache.org/foundation/bylaws.html for more information.
5.9 In the unlikely event that a member of the PMC becomes disruptive to
the process, ceases to make codebase contributions for an extended
period, or ceases to take part in PMC votes for an extended period of
time, said member may be removed by unanimous vote of remaining PMC
members.
5.10 The PMC is responsible for maintaining and updating this
charter. Development must follow the process outlined below, so any
change to the development process necessitates a change to the
charter. Changes must be unanimously approved by all members of the
PMC. A contributor may challenge a change to the charter at any time
and ask for a vote of all xml.apache.org active committers, in which
case a two-thirds majority must approve the change.
6 SUBPROJECTS
=============
6.1 xml.apache.org is comprised of subprojects; a subproject is
responsible for component or application whose scope is well defined.
Each subproject has its own set of developers, and is responsible
for approving its own committers.
6.2 A new subproject proposal is submitted to the PMC, and then accepted
by a majority xml.apache.org active committer vote.
6.3 A subproject may be removed by unanimous vote of the PMC, subject to the
approval of the ASF board. A contributor may challenge the removal of a
subproject at any time and ask for a vote of all active committers, in
which case a two-thirds majority must approve the change.
7 CONTRIBUTORS
==============
7.1 Like all Apache projects, the XML project is a meritocracy -- the more
work you do, the more you are allowed to do. Contributions will include
participating in mailing lists, reporting bugs, providing patches and
proposing changes to a product.
7.2 Developers who make regular and substantial contributions may become
committers as described below.
8 COMMITTERS
============
8.1 Each subproject has a set of committers. Committers are contributors who
have read/write access to the source code repository. New committers
are added when a contributor is nominated by a committer and approved by
at least 50 percent of the active committers for that subproject with no
opposing votes. In most cases, new committers will already be
participating in the development process by submitting suggestions
and/or fixes via the bug report page or mailing lists.
8.2 For the purposes of voting, committers will be classed as "active" or
"inactive". Only active committers will be included in the totals used to
determine the success or failure of a particular vote.
8.3 Committers remain active as long as they are contributing code or
posting to the subproject mailing lists. If a committers has neither
contributed code nor posted to the subproject mailing lists in 3
months, the PMC representatives for that subproject will e-mail the
committer, the subproject development list, and the PMC mailing list
notifying the committer that they are going to be moved to inactive
status. If there is no response in 72 hours, the committer will become
inactive.
8.4 An inactive status will not prevent a committer committing new code
changes or posting to the mailing lists. Either of these activities will
automatically re-activate the committer for the purposes of voting.
9 INFRASTRUCTURE
================
9.1 The xml.apache.org project site must provide the following:
a) Bug Database -- This is a system for tracking bugs and feature
requests.
b) Subproject Source Repositories -- These are several repositories
containing both the source code and documentation for the
subprojects. Each subproject will have a set of committers to its
repository.
c) Website -- An xml.apache.org website will contain information about
the xml.apache.org project, including documentation, downloads of
releases, and this charter. Each subproject will have its own website
with subproject information.
d) PMC Mailing List -- This list is for PMC business requiring
confidentiality, particularly when an individual or company requests
discretion. All other PMC business should be done on the general
mailing list.
e) General Mailing List -- This mailing list is open to the public. It is
intended for discussions that cross subprojects.
f) Subproject Mailing Lists -- Each subproject should have a devoted mailing
list. Many subprojects may wish to have both user and development
lists. The individual subprojects may decide on the exact structure of
their mailing lists.
10 LICENSING
===========
10.1 All contributions to the xml.apache.org project adhere to the "ASF
Source Code License." All further contributions must be made under the
same terms. All contributed files must contain the full text of the ASF
Source Code License.
11 THE DEVELOPMENT PROCESS
==========================
11.1 The development process is intentionally lightweight; like other
Apache projects, the committers decide which changes may be committed
to the repository. Three +1 ('yes' votes) with no -1 ('no' votes or
vetoes) are needed to approve a code change. For efficiency, some code
changes from some contributors (e.g. feature additions, bug fixes) may
be approved in advance, in which case they may be committed first and
changed as needed, with conflicts resolved by majority vote of the
committers.
12 SUBPROJECT REQUIREMENTS
==========================
12.1 Each subproject must have a set of requirements as well as an
up-to-date release plan and design document on its dedicated web page.
12.2 It is recommended that each subproject have a smoke-test system
that works at least as a basic integration test.
13 RELATIONSHIP TO OTHER APACHE PROJECTS
========================================
13.1 The xml.apache.org project should work closely with other Apache
projects, such as Jakarta and the Apache Server, to avoid redundancy
and achieve a coherent architecture among xml.apache.org and these
projects.
Projects
The Apache XML Project currently consists of a number of sub- projects, each focused on a different aspect of XML:
- Xerces - XML parsers in Java, C++ (with Perl and COM bindings)
- Xalan - XSLT stylesheet processors, in Java and C++
- FOP - XSL formatting objects, in Java
- Forrest - XML/XSLT project community websites
- Xang - Rapid development of dynamic server pages, in JavaScript
- SOAP - Simple Object Access Protocol
- Batik - A Java based toolkit for Scalable Vector Graohics (SVG)
- Axis - A Java based implementation of SOAP
- Commons - A meta-project of common XML-oriented code
- Security - Java and C++ libraries for encryption and signature functions