(I subscribed to this list for the sake of contributing till the end of the week as I'm leaving for a 5 week vacation so I won't bother you too much :-)
 
[...]
>So it isn't quite true to say that xmlParserAPIs.jar can always be replaced
>by xml-apis.jar. But perhaps more fundamentally, for applications which,
 
...uh... sorry but that does not help AT ALL.
what are you telling me here ? that the xalan distrib is not correct because it does not have xmlParserAPIs and that it should be there + xml-apis.jar which should be in fact xsl-apis + dom-css.apis, etc ?
 
>unlike Ant, have no need for an XSLT processor, having the transform half
>of JAXP around is at best superfluous.  Indeed, JAXP is a bit of a weird
>API in that it contains two independent halves which are almost guaranteed
>to be implemented by different products.
It's not superfluous at all, a vast majority of users use the transformation part. <style> is part of many build files that generate documentation or code from xml or anything and many tasks use the identity transformation as this is the standard way to serialize an xml document...
 
>So xerces-J has always taken the position that for us to ship the transform
>API's would at least waste bandwidth/space, and would very likely be
 
I'm not sure that the 'bandwith/space' is valid when looking at the jar size...
 
xml-apis.jar: 190 files, 105kb
xmlParserAPIs.jar: 129 files, 128kb
 
the core xerces parser is 1.6MB...we are talking about what here ? 10kb bandwidth issue ?
1% of the total size ? come on ! I fail to see this as a -real- problem.
 
memory ? not an issue as well.
 
[...]
>Hopefully that'll help explain some of the background of why things are as
>they are.  I don't think anyone's quite happy with this, but so far what
>attempts have been made to try and fix things have had no palpable
>success...

I read the JAXP 1.1 specs as being javax.xml.parser and javax.xml.transform. So the interface should all be at the same place otherwise we are shooting ourselves in the foot again and we will replicate the issue whenever a new version will slowly appear to replace another. We'll have what ? 1.3 in one half and 1.2 in another half ? xerces and xalan have different release cycles so anyone could need xalan A.B (shipped with Xerces C.D) but need to use Xerces C.E but Xerces C.E is certified with xmlParserAPIs ..that is incompatible with xml-apis ...
 
Wait until DOM3 starts to spread and once again we'll have 'DOM3 vs DOM2' ClassCastException...well things changes..til last year it was not rare to have DOM1 vs DOM2.. :)
 
I was in favor of splitting the xml apis into smaller chunks, 'dom2.jar', 'sax2.jar', 'jaxp.jar', this makes things crystal clear and classpath are no more an issue anyway. I did not type a classpath for more than 2 years now.
 
To me it is kind of necessary to do this chunking if you don't want to ruin the effort of thousands of people in an app. server that is able to load either xmlParserAPIs or xml-apis first...
 
By splitting the xml-apis into smaller chunks we are able to replace easily the interfaces by more appropriate one if necessary rather than hack jars to remove some of them. This is more modular.
version n+1 is normally backward compatible to version n, so dom3.jar can replace dom2.jar but the reverse is far from being true and if you have both of them loaded randomly...you know the result.
 
IMHO this is something to consider...
 
Stephane