XML Graphics PMC discussion

Discussion takes place on general@xml.apache.org. You're free and encouraged to help improve this proposal.

Overview

In light of the recent /FederationProposal the XML subprojects Batik and FOP are investigating the possibilities for moving closer together, namely creating a new PMC for these two subprojects. There are a number of potential benefits, but also fears, to be addressed. The purpose of this page is to identify the benefits as well as address (and hopefully alleviate / minimize) those fears.

Motivation

• The board's request to establish better oversight within the XML project makes it necessary for its subprojects to think about the way to go on when the federation proposal gets put to action.
• Batik and FOP each implement an XML standard which generates graphical output.
• Batik and FOP recognize potential benefits from sharing parts of their code.

• FOP created and maintains PDF and { { { PostScript } } } transcoders (Batik output plug-ins) which should at least be accessible to Batik committers for maintenance.

• FOP's transcoders currently get used in Batik releases without really being involved in the release process.
• FOP and Batik might be too feeble ATM to become top-level projects each by themselves. Each subproject becoming a TLP has the potential problem to render collaboration more difficult.

Code sharing and separating components

The biggest issue between FOP and Batik are probably the two transcoders. Within FOP the PDF and { { { PostScript } } }/EPS transcoders were created out of a need for SVG support for these two output formats within FOP. In the future there could be additional output formats (PCL for example). Batik committers have no write access to the transcoders and have to submit patches to help maintain the code that is highly dependent on Batik code.

Both transcoders rely on parts specific to FOP. These are:

• PDF library

• Font support libraries ({ { { TrueType } } } and Type 1 fonts, parsers and font metric providers)

• { { { PostScript } } } generation utilities provided by the { { { PostScript } } } renderer

• Configuration
• Character normalization and line breaking code (for SVG flow text)
• Bitmap image loading code (different approaches between Batik and FOP)
• font and URI/URL resolution

This means that when the two transcoders are broken out of FOP's main codebase, the above parts need to be looked at closely. In particular, things like the PDF and font support packages should probably be made separate components. They might even profit from a separation as they are usable independently of FOP. As separate components they could get greater visibility and even attract contributors on their own.

An important point in this discussion is the release process. When Batik does a release it currently includes the PDF transcoder from FOP. The problem with this is that the PDF transcoder itself has not yet been released by the FOP team. Making the necessary parts individual, and more important, shared components that can be released independently, this problem could be better addressed.

What the XML Graphics effort could look like

• Creation of a new PMC comprised of most or all committers of the current Batik and FOP subprojects. The PMC reports directly to the board and is directly involved in the release process. All PMC members must be subscribed to all development mailing lists under this PMC and must monitor the developments.
• We should avoid any visible changes for our users (especially web site and mailing lists). Both projects are established projects with a large user base. We should take pains not to do anything that could potentially hurt our user base.
• Both Batik and FOP implement a different specification (SVG and XSL-FO), so it makes sense to continue running both as separate subprojects with a separate set of committers under the XML Graphics PMC.
• The user communitites of FOP and Batik are equally different, so the user mailing lists should remain separate.
• Both FOP and Batik will stay accessible from the XML project's website so nothing changes for our users.
• We might create a TLP site xml-graphics.apache.org.
• Apart from the new PMC mailing list there could be a common mailing list where development on shared components is discussed.
• We continue to use the infrastructure provided by the XML project/federation.
• In the future, additional projects doing XML-to-Graphics conversion could be taken on-board.

Potentially problematic points

• FOP has recently voted in new committers who may have contributed too little yet (in the view of some) to already become committers. This was primarily due the fact that a lot of old FOP comitters became inactive during the last two years and some of the FOP committers wanted to help "reignite" the project. Although Batik seems to have similar problems, they haven't taken similar steps. If this is a problem for the Batik people, especially since the common components will be accessible to FOP as well as Batik committers, we'd like the Batik people to speak up. (See also http://nagoya.apache.org/eyebrowse/ReadMsg?listName=fop-dev@xml.apache.org&msgId=1326085)

TODO

• Continue the discussion on this topic.
• Write a proposal to the board for creation of the PMC (if this idea finds enough support)
• Find alternative solutions to address the board's request if this idea cannot be pursued due to lack of support.