Status: Withdrawn Reason: Since version 1.0, JSR 173 StAX API has been distributed as both a standalone technology and part of the Java SE. The API has been stable without any significant changes since then and the need to use newer releases of the StAX API with shipping releases of Java SE has mostly disappeared in recent years.

In accordance with JCP 2.10 Process Document, 3.3.1.4 Platform inclusion, we are announcing the end of JSR 173 StAX Standalone distribution. After MR5, StAX 1.4, the technology that JSR 173 defines will be delivered as a part of the Java SE solely. Future changes in the StAX API will be defined through the Platform JSR.

The subsumption of the StAX API into the Platform JSR does not change any mechanisms defined in StAX. The service provider interfaces are the same except that they will then be directly specified in the Platform JSR. Deployment of alternative implementations of the StAX APIs will continue to be supported.JCP version in use: 2.10Java Specification Participation Agreement version in use: 2.0

Description:
The Streaming API for XML (StAX) is a Java based API for pull-parsing XML.

This JSR has been Withdrawn Reason: Since version 1.0, JSR 173 StAX API has been distributed as both a standalone technology and part of the Java SE. The API has been stable without any significant changes since then and the need to use newer releases of the StAX API with shipping releases of Java SE has mostly disappeared in recent years.

In accordance with JCP 2.10 Process Document, 3.3.1.4 Platform inclusion, we are announcing the end of JSR 173 StAX Standalone distribution. After MR5, StAX 1.4, the technology that JSR 173 defines will be delivered as a part of the Java SE solely. Future changes in the StAX API will be defined through the Platform JSR.

The subsumption of the StAX API into the Platform JSR does not change any mechanisms defined in StAX. The service provider interfaces are the same except that they will then be directly specified in the Platform JSR. Deployment of alternative implementations of the StAX APIs will continue to be supported.

2.15 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:

* Is the schedule for the JSR publicly available, current, and updated regularly?
Answer:
The JSR is currently going through a maintenance release which will be on the same schedule as the JDK 8, which is available publicly

* Can the public read and/or write to a wiki for the JSR?
Answer:
Yes – the wiki is available on the java.net project for JSR 173 at http://java.net/projects/stax-spec

* Is there a publicly accessible discussion board for the JSR that you read and respond to regularly?
Answer:
Publicly accessible mailing lists (jsr173-experts@stax-spec.java.net, users@stax-spec.java.net ) with online browsable archives have been created for JSR-173. These can be used for discussion. These are newly created as of April 2013 and I will be monitoring and responding to them regularly.

* Have you spoken at conferences and events about the JSR recently?
Answer: No

* Are you using open-source processes for the development of the RI and/or the TCK?
Answer:
The RI is an open source project on Java.net. The TCK was developed at the time of original JSR release. It is not currently available on a public open source website but can be made available if needed.

* What are the Terms of Use required to use the collaboration tools you have prepared to use with the Expert Group, so that prospective EG members can judge whether they are compatible with the JSPA?
Answer:
For future releases including maintenance release currently underway, the mailing list given above (jsr173-experts@stax-spec.java.net) may be used.

2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

2.1 Please describe the proposed Specification:

The Streaming API for XML (StAX) parsing will specify a Java-based, pull-parsing
API for XML. The streaming API gives parsing control to the programmer
by exposing a simple iterator based API. This allows the programmer to
ask for the next event (pull the event) and allows state to be stored in
a procedural fashion.

Two recently proposed JSRs, JAXB and JAX-RPC, highlight the need for
an XML Streaming API. Both data binding and remote procedure calling (RPC)
require processing of XML as a stream of events, where the current context
of the XML defines subsequent processing of the XML. A streaming API makes
this type of code much more natural to write than SAX, and much more efficient
than DOM.

The goal of this API is to develop APIs and conventions that support
processing XML as a stream. The specification will address three main areas:

Develop APIs and conventions that allow a user to programmatically pull
parse events from an XML input stream.

Develop APIs that allow a user to write events to an XML output stream.

Develop a set of objects and interfaces that encapsulate the information
contained in an XML stream.

The specification should be easy to use, efficient, and not require a grammar.
It should include support for namespaces, and associated XML constructs.
The specification will make reasonable efforts to define APIs that are
"pluggable".

Non-goals of this specification include:

Specifying a validation API. Validation will be done in the layer above
the streaming parser. This does not preclude passing validation parameters
to an underlying parser.

2.4 Why isn't this need met by existing specifications?

To use SAX one writes handlers (objects that implement the various SAX
handler APIs) that receive callbacks during the processing of an XML document.
The main benefits of this style of XML document processing are that it
is efficient, flexible, and relatively low level. It is also possible to
change handlers during the processing of an XML document allowing one to
use different handlers for different sections of the document. One drawback
to the SAX API is that the programmer must keep track of the current state
of the document in the code each time one processes an XML document. This
creates overhead for XML processing and may lead to convoluted document
processing code.

DOM

DOM provides APIs to the programmer to manipulate the XML as a tree.
At first glance this seems like a win for the application developer because
it does not require writing specific parsing code. However this perceived
simplicity comes at a very high cost: performance. Some implementations
require the entire document to be read into memory, so for very large documents
one must read the entire document into memory before taking appropriate
actions based on the data.

Another drawback is the programmer must use the DOM tree as the base
for handling XML in the document. For many applications the tree model
may not be the most natural representation for the data.

2.5 Please give a short description of the underlying technology or technologies:

Standard XML parsing technology.

2.6 Is there a proposed package name for the API Specification? (i.e.,
javapi.something,
org.something, etc.)

javax.xml.stream.*

2.7 Does the proposed specification have any dependencies on specific operating
systems, CPUs, or I/O devices that you know of?

No.

2.8 Are there any security issues that cannot be addressed by the current
security model?

No.

2.9 Are there any internationalization or localization issues?

Must handle standard character encodings.

2.10 Are there any existing specifications that might be rendered obsolete,
deprecated, or in need of revision as a result of this work?

No, may need to revise JAXP, JAXB and JAX-RPC to take advantage of this
work.

2.11 Please describe the anticipated schedule for the development of this
specification.

The final schedule will need to be determined by the expert group. However,
it is anticipated that a reasonably solid draft should be available in
the Fall.

2.12 Please describe the anticipated working model for the Expert Group
working on developing this specification.

It is anticipated there will be a face-to-face kick-off meeting. Subsequent
work will be done by email. First we will define use cases, then we will
focus on APIs.

The goal will be to attempt to develop a consensus in the expert group
over the main APIs and technologies.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations
that describe the technology. Please include links to the documents if
they are publicly available.