Hi Stephane,

>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 ?

"Not correct" is certainly not what I'm saying.  I'm saying that xalan has
a different perspective on packaging than I do (is there ever a "correct"
in issues like this?)  I just don't think this is a very good approach for
a parser to adopt, so I hope Xerces-J won't adopt it.

>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...

You know your users, so I have no doubt you're right that a vast majority
of projects that have build files and tasks (i.e., which are Ant users) use
xalan.  Xerces-J included BTW.  :-)  But the world is made up of more than
ant users, and I'm still quite convinced there are a large number of
applications which require a parser but not an XSLT engine.

>xml-apis.jar: 190 files, 105kb

hmmm; I just checked out xml-commons and built it and I got 119 Kb...

>xmlParserAPIs.jar: 129 files, 128kb

That's because, traditionally, Xerces-J hasn't compressed its jars.  We've
pretty much decided to give this a whirl for our next minor release and see
what the reaction is.  As of now xmlParserAPIs.jar is 79K--a 50% savings
over xml-apis.jar as of this morning.

>the core xerces parser is 1.6MB...

About 870K after compression.  So the difference of adding these APIs that
we neither use nor implement is not vast, but still tangible.  It's still
the fact that including them is, to my mind, misleading that is my primary
source of discomfort with the idea though.

>so anyone could need xalan A.B (shipped with Xerces C.D)

You mean "which ships" here right?

>but need to use Xerces C.E but Xerces C.E is certified with xmlParserAPIs
>..that is incompatible with xml-apis ...

I fail to see how this is a problem if these jars were disjoint.  xalan has
to rely on a parser, so the parsing APIs it uses have to be <= xerces's
(unless xalan adopts another parser).  So if you need a more modern xerces
than what xalan ships with, assuming the APIs xerces implements are as
backward-compatible as you hope they will be there should never be any
problems...

>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.

And the only reason to keep JAXP in one jar is that it calls itself a
single API?  It's a reason I'll admit, but I'm not convinced it's a good
one.

>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.

Exactly.

Cheers,
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone:  905-413-3519, T/L 969-3519
E-mail:  neilg@ca.ibm.com



---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org