xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephane Bailliez" <sbaill...@apache.org>
Subject Re: XML APIs in Xalan and Xerces
Date Tue, 16 Apr 2002 22:06:34 GMT
(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

Mime
View raw message