JAXP.next JSR Proposal

[Jeff Suttor <Je...@Sun.COM>]

dear Xerces-J-Dev & Xalan-Dev,

a new JSR Proposal:

JSR 206 Java(TM) API for XML Processing (JAXP) 1.3

has been posted at:

http://jcp.org/en/jsr/detail?id=206

would it be possible for people to take a look and make comments over
the next few days with the goals of:

- insuring that the JSR will be of maximal value to the Java/XML user
community
- working toward the Apache Software Foundation being able to vote yes
on the JSR Proposal moving forward
- identifying individuals that would participate on the Expert Group as
the Apache Software Foundation representatives

note that the JSR Proposal is only meant to identify the needs of the
Java/XML community and guide the expert group, not to be a comprehensive
enumeration of what will be done or prescriptive of how it will be done.

when thinking about the scope of this JSR Proposal, keep in mind that it
will have a relatively short cycle time, for standards work :), as it is
destined for inclusion in J2SE(TM) 1.5.  that translates to Community
Review in August.  see Section 2.14 of the JSR Proposal for
acknowledgment that the XML space will continue its rapid evolution and
there will be a need to revise JAXP outside of the J2SE(TM) release
schedule.

if there's anything I can do to help out in any way, please contact me
at any time.

thanks,

-- 
Jeff Suttor
+1 650 352 6340
Jeff.Suttor@Sun.com


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org

Re: JAXP.next JSR Proposal

[Elliotte Rusty Harold <el...@metalab.unc.edu>]

I think this JSR needs to take a very serious look at how the 
standardization of SAX/DOM/TrAX within the JDK/JRE hinders the 
development and use of those specifications within the Java 
community. JAXP compatibility has been a significant drag on the XML 
Apache Project for some time and others as well. JDOM, for instance, 
has had to handcraft its code to avoid compile time dependence on 
JAXP. See for instance, this thread: 
http://lists.denveronline.net/lists/jdom-interest/2003-February/012086.html

In particular, changes that need to be adoipted include:

1. The parser and other libraries must not be part of the classes.zip 
file that holds the core Java library. I do think a parser and 
implementation should ship with the JDK. However, it should be able 
to be easily overridden or replaced by the end user. It should not be 
necessary to know the magic jre/lib/endorsed incantations just to 
choose a different parser. User parsers and implementations anywhere 
in the classpath should override the default parser.

2. It needs to be established that third parties such as the Apache 
project and the W3C can ship JAXP even if they are using a more 
recent version of an API such as SAX or DOM that adds additional 
methods and classes, and thus flunks the compatibility tests.

In brief, Sun needs to accept that SAX and DOM are third-party 
standards that are not and will not be defined in the JCP. They 
cannot be treated the same as core parts of the Java class library 
such as the Collections API. Sun can adopt these standards for use in 
the Java API, but it should recognize that it does not provide the 
only or the official definition of these APIs.

-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|           Processing XML with Java (Addison-Wesley, 2002)          |
|              http://www.cafeconleche.org/books/xmljava             |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+