xml-commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From shane_curc...@us.ibm.com
Subject Re: Xerces 2.0.0 beta 4 causes Xalan to glitch
Date Thu, 20 Dec 2001 17:46:59 GMT
(Arrrgggh: marc.theaimsgroup.com's archives have dropped a number of recent
xerces-j-dev posts, which is why I haven't been participating on this
thread.)

> > joseph_kesselman@us.ibm.com wrote:
> >General comment:  Factoring out the standards is a fine idea -- Xalan
also
> >did so, with its xml-apis.jar file -- but unless Apache can reach a
> >consensus on a _common_ factoring, the idea simply does not achieve its
> >goals.

>  neilg@ca.ibm.com wrote:
> But the factoring has to depend on the characteristics of the product
being
> factored.  We just don't support javax.xml.transform stuff, so why would
we
> distribute it?  This is the only reason we call our API jar something
> different than you call yours; but ours should be as close to a proper
> subset of yours as different source repositories will allow.

My vote goes with Joseph on this one: we should either agree to work on
commons-dev to have an official 'release' of the xml-commons externally
defined standards code packaged in xml-apis.jar and then all use *that*
.jar file, or we might as well just leave it to each product to do as they
please.

It wouldn't hurt anything for Xerces to include the extra JAXP transform
interfaces; they'd politely throw the proper exceptions if called, and only
add a small amount of space.  But the real point is not that Xerces is
shipping this code or that .jar, the point is that you'd be shipping the
'product' of the xml-commons external xml-apis.jar.  If you do that, you
take the whole thing, not just part of it.  (Obviously serious issues like
versioning, etc. still need to be worked out there, but for just SAX 2.0,
DOM L2 and JAXP 1.1.x - pick your x - we should be able to do that pretty
quickly.)

> > I'm not saying that xml-apis.jar is necessarily right and
> > xmlParserAPIs.jar is necessarily wrong, but the two should agree on
what is
> > and isn't an XML API and have, at worst, equivalent content. (I would
> > really like to see a _single_ xml APIs jarfile for all of Apache, to
> > guarantee we're all speaking the same language -- with local overrides
if
> > necessary for prototype APIs, which could be placed earlier on the
> > classpath if and only if there's an intent to use the prototypes.)

> Even for products which don't support all API's?
Yes.  Products should either take the xml-apis.jar (or any specific version
they need) as-is, or not at all.

Of course if the xerces community does want to do their own packaging
thing, that's fine - it's up to each community to decide.  But I was hoping
that with time the xml-commons community would get more and more of the
xml.apache communities to agree on one standard.

> Perhaps a better solution
> would be to have some sort of lowest common denominator API jar (perhaps
> even xmlParserAPIs.jar) that all products will either implement or rely
> upon, and split other API content into jarfiles that can then be shipped
by
> the particular products that implement them?

If we want to re-open the previously discussed xml-commons packaging
scheme, we should do that on commons-dev or maybe general.  At one point,
we specifically decided against separate dom.jar/sax.jar/jaxp.jar files,
both because there's too many; most common usages will require all three
anyway; the interfaces code size is not that big unless you're being
super-optimized; and because there are plenty of pre-existing files shipped
with older spec versions called dom.jar, sax.jar, and jaxp.jar, which is
quite confusing for users.

For now, the xml-commons community decided specifically on 'xml-apis.jar'
and that it should include SAX 2.0, DOM L2, and JAXP 1.blah.  The blah
portion was perhaps never quite as specific as it might have been; it
sounds like now we'll really have to have an xml-apis.jar version that has
*just* the JAXP 1.1 code so servlet vendors can get the J2EE 'testing
certification' that people seem to want today, and a newer xml-apis.jar
version that has the current code.

- Shane,
(not subscribed, but now using both marc.theaimsgroup.com and
mail-archive.com to read lists...)


Mime
View raw message