Hi again Neil,

(and thanks for taking the time to reply about these boring issues)

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

by correct I meant that I understood that it is not what we would call hem
'certified APIs'.

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

certainly but now that there is a standard way to serialize a document, that
somewhat means we need an xslt engine..unless we use a proprietary API...and
until DOM3 is out.


> >xml-apis.jar: 190 files, 105kb
> 
> hmmm; I just checked out xml-commons and built it and I got 119 Kb...

can't comment on this, this is what I have from Xalan 2.3.1...so I don't
know for sure

[...]
> About 870K after compression.  So the difference of adding 
> these APIs that
> we neither use nor implement is not vast, but still tangible. 

'negligible'. :)

>  It's still
> the fact that including them is, to my mind, misleading that 
> is my primary
> source of discomfort with the idea though.

I understand your point of view for this, but then the problem is that you
ship 'some version' of jaxp..that I don't know about easily. Take this from
a deployment point of view. xmlParserAPIs.jar has no manifest with the JAXP
version number. Not many people know the core difference between 1.1 and
1.1.2 and but I know there are some non negligible, should it be about
classloader issue or factory caching.

If you keep this jar, I would suggest adding a manifest the way xalan folks
do.
It's easier to identify the version this way.

> >so anyone could need xalan A.B (shipped with Xerces C.D)
> 
> You mean "which ships" here right?

Yes sorry.

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

If the implementation is different it is a problem.

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

It's better to have it all in one single place as this is the same api and
there is the contraint of having a unique version of jaxp..we should not
have to play Lego (tm) to assemble an interface into a fully fonctional one
as identified per specifications.

Same for me about DOM for example. I would rather see all interfaces in one
jar than part of it as some parts are optional but at least if you need to
use XML heavily these interfaces exists, they are available, you can use
them, they are here. Why not using the dom2.jar available from
http://www.w3.org/DOM/DOMTM ?



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