(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
xml-apis.jar. But perhaps more fundamentally, for applications
...uh... sorry but that does not help AT
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,
>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
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
>So xerces-J has always taken the position that for us to ship the
>API's would at least waste bandwidth/space, and would very
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
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
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
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...