| ## Expat Development Roadmap
## PROPOSAL Updated 5 September 2002. This is a proposed roadmap for the further development of Expat. The primary purpose for making this proposal is to determine whether our ideas for continued development are aligned with the needs of the community. We welcome comment both from Expat users, would-be users, and members of the XML community who have decided against using Expat for technical reasons directly related to Expat. Discussion of this document should be directed to the expat-discuss mailing list. ### Goals We do not plan to alter the goals of the Expat project. We intend to continue to develop Expat to have the following qualities: Fast Conformant to XML 1.0 and Namespaces Easy to use from C Easy to wrap / bind for non-C languages Sufficient to build DOM and SAX on top of (any final specification for XML) Modest memory footprint Portable ### Non-Goals Parsing anything that isn't XML DOM (any level) SAX (any version) Data bindings Watching the kids ### Historical Background James Clark initially developed Expat, releasing three stable versions, identified as versions 1.0, 1.1, and 1.2. Clark Cooper created a forked version of Expat based on Expat 1.1, for use in the XML::Parser extension module for Perl. As James Clark's interests shifted, and his development moved to the Java environment, the authors of 3rd party language bindings found it increasingly difficult to integrate Expat with their languages, and other developers found it difficult to get fixes accepted into Expat and released. A small group of extension authors were gathered by Paul Prescod in the hope that Expat could be formed into a more readily usable library for both direct use in C-language applications and indirect use from other languages. This group was led by Clark Cooper and Fred Drake, and received sanction to take over maintenance of Expat from James Clark. The project is hosted on SourceForge. This group made their first release as Expat 1.95.0 in September 2000. Since that time, incremental releases of Expat have been made on a sporadic schedule, improving functionality and portability with each release. ### Expat Development Roadmap Now that our goals and non-goals have been spelled out, let's take a look at how we should get there from where we are now. This will be broken down into two stages: near future activities and far future activities. In spite of the somewhat temporal labeling of these categories, please realize that no actual scheduling has been done, nor is that considered relevant at this time. Actual time to meet these goals is dependent on the availability of resources to work on Expat. Parallel development may also happen, depending on the specific interests of contributers. #### Near Future Activity The target of the current line of development will be to release Expat 2.0. The intent is that once Expat 2.0 is released, most of the development activity for this line will be maintenance, and will be driven by user-provided problem reports. These are the goals for goals we have specific to the release of Expat 2.0: Stabilize the current API with some minor revisions to make error reporting more explicit to allow better reporting and diagnosis. Introduce a new feature-test macro, XML_MINIMAL, parallel to XML_DTD, XML_UNICODE, and XML_UNICODE_WCHAR_T. Defining the new feature when compiling Expat will cause functions that are not relevant to the rest of the feature macros. (For example, if XML_DTD is not set but XML_MINIMAL is, the functions that set handlers for DTD-related events won't be included at all.) This is intended to make it easier to use Expat in small-memory devices. API revisions will be made to improve the runtime discoverability of Expat capabilities. Improve portability and performance. Substantially improve regression tests. Improve documentation. Full support for 64-bit platforms. (There are some known decoding problems currently.) When we're confident that the minor API changes are "right", we'll finallize the API and release Expat 2.0. Should additional functions be required as evolutionary improvements, the minor version number will be incremented, but all existing functions will be maintained for backward compatibility. Releases that are strictly bug fixes will have the same minor version number and will gain a "micro" version number (sometimes called a "patch level"). #### Far Future Activity Once Expat 2.0 has been released, it will be maintained on a CVS branch. The head of CVS will be used to develop Expat 3.0. The changes in Expat 3.0 will be more substantial and will include important API changes. At this time, we're looking at the following changes: More powerful event API The new API will be sufficiently detailed that a complete and detailed DOM structure can be built, including both internal and external entity boundaries in parsed character data content, attribute value content, and entity values (such as found in internal entity declarations). This API will of necessity be somewhat more complex than the current API, but we expect the current API can be implemented on top of the new API. For users for whom the Expat 2.0 API is sufficiently powerful, this API will remain available. Support for either pull or suspendable parsing The new API will need to support some way to interrupt processing without having to parse all XML text passed to the parser so far. This can be done by either using a pull-based model or a push-based model (similar to the current API) with the added ability to suspend parsing on request. The specific API will depend on the model selected; either a pull-based model or an suspension model can support each other with little additional work, and the current push model can be built on top of either. The specific model and API will be discussed on the expat-discuss mailing list. New encoding support A new library may be added to the Expat package that provides a flexible architecture for defining new encodings, and provides a large range of common encodings. (It should be possible to develop this so that it supports both Expat 2.0 and Expat 3.0.) Another approach which will be considered will be to support Expat's requirements for decoders using one of the existing open source encoding support libraries that meets Expat's requirements for portability. Possible technical approaches would include implementing an adapter, and developing such an external library to include direct support for the kind of interface support Expat needs. XML 1.1 (including Namespaces in XML 1.1), if it ever happens Well, we're hoping, but it's not time to code for this yet. Additional goals may be added during the development of Expat 3.0; it's just too early to tell.