xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Leung" <twle...@sauria.com>
Subject Re: JDOM in Apache (was Re: xml.apache.org charter proposal)
Date Fri, 30 Mar 2001 18:15:55 GMT

----- Original Message -----
From: <Scott_Boag@lotus.com>
To: <general@xml.apache.org>
Sent: Friday, March 30, 2001 9:29 AM
Subject: JDOM in Apache (was Re: xml.apache.org charter proposal)


>
> "Brett McLaughlin" <brett@newInstance.com> wrote:
> > I'm curious about this. You say that it would be OK to write code in
> Xerces
> > that would build a JDOM document; yet at the same time it's not OK to
> bring
> > in JDOM code? How is that different from having to bring in the SAX or
> DOM
> > classes? I'm of course not wanting a fight here, just some clarification
> ;-)
>
> First, it would be nice, and is probably possible with XercesJ2, to use
> Xerces without their default DOM implementation.  I, in fact, would like
to
> see the DOM implementation in a separate JAR.  But the DOM interfaces are,
> perhaps a different matter.  I would like to see DOM interfaces in a AXDK
> project, but not JDOM, because the DOM is a set of interfaces, and JDOM is
> an implementation.  I know we have a disagreement here, but this is a
> *huge* difference in my mind.

It is actually possible today in XercesJ1 to do this.  Creative use of jar
will do the job.
If JDOM became a set of interfaces would that change your mind or would it
take
something more?  I'm trying to understand the criteria here.

> Second, SAX2 is mainly pure interfaces, so I think it's a different beast
> from the Xerces DOM implementation.  I believe SAX exceptions are probably
> pervasive in the Xerces code, but I haven't closely enough to say this one
> way or the other.  The SAX layer is pretty thin on Xerces.
>
> Third, I *would* very much like to see a non-object non-event interface on
> Xerces (see the new DTM stuff we're doing and some of my notes on
> xalan-dev... see:
>
>
http://xml.apache.org/websrc/cvsweb.cgi/xml-xalan/java/src/org/apache/xml/ut
ils/DTM.java
>
http://xml.apache.org/websrc/cvsweb.cgi/xml-xalan/java/src/org/apache/xml/ut
ils/DTMFilter.java
>
http://xml.apache.org/websrc/cvsweb.cgi/xml-xalan/java/src/org/apache/xml/ut
ils/DTMIterator.java
>
http://xml.apache.org/websrc/cvsweb.cgi/xml-xalan/java/src/org/apache/xml/ut
ils/DTMManager.java
>
> ...we'll also have DTM2DOM and DOM2DTM classes.
>
> )
>
> The idea is that Xalan will pass nodes as integer handles instead of
trying
> to directly use the DOM interfaces (or any other object-based interfaces),
> which require object creation.  (Note, BTW, that this scheme will make it
> far easier to make DTM2JDOM and JDOM2DTM classes like we'll have DTM2DOM
> and DOM2DTM classes... we'll just need a lookup table, instead of full
> proxies.)
>
> I would like to eventually see a direct implementation of these interfaces
> by XercesJ2, because there's a lot you can do in terms of performance by
> having a close-coupling relationship of a DTM implementation with the
> parser.  Also, it is possible to implement "pull" parsing within the
> implementation of this interface, but that will have to be done at a level
> of coupling beyond JAXP 1.1 or SAX2.

I agree that this would be *wonderful* for performance.   If this is you
objective,
you need to speak up quickly.  The current X2 design calls for all integer /
StringPool
based stuff to be done away with.  The discussion would benefit greatly from
your
participation.

> Anyway, my point is that Xerces code dependencies should be really
limited.
> Standardization isn't so much the issue, though it is an issue.  As you
> say, JDOM is moving to some level of standardization in the JCP.  But I
> would like not to bloat the Xerces2 code more than absolutely necessary.

Suppose we do an AXDK and people start asking for us to include JDOM.  What
happens then?

> Hmm... let me say one more thing that may be controversial.  Though I am
an
> individual on Apache, I am also an employee of IBM, and I believe in my
> company's software strategy.  We have a commitment to the standards
> developed in the W3C, and I believe they hold the best chance of
delivering
> the XML vision.  There's lots of things I don't like about the DOM, and
> things I don't like about the process of design in the W3C, but I
> fundamentally believe that the W3C has done a very good job at developing
> standards that can be used for commercial software development.  The DOM
> needs work... a read-only API, better alignment with the infoset, better
> constraint on new features, and maybe an alternate Java binding.  But the
> DOM works for me as an implementation independent tree API to information
> providers, while JDOM doesn't meet my criteria of being simply a set of
> interfaces from which to access infoset information.  I also believe that,
> at this time, the W3C is much more neutral ground and more fair than the
> JCP process.  If Sun fixes some of their procedure rules, releases some
> control, fixes their licences, and does a better job at developing a true
> community, I believe this can change.  I am hopeful about the JCP, but I
> don't believe it's there yet.
>

I think that we are all entitled to our opinions of the various "standards"
bodies,
and to our own ideas of what constitutes a decent XML strategy.  I've no
issue
with that.  The ASF has historically been viewed as vendor neutral.   I do
not
want us to move in a direction of "approving" any vendor's software
strategy.
It's not in the interest of the ASF, and it's not in the interest of venders
who
participate here under some marketing story about openness, vendor
neutrality,
and so forth.



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


Mime
View raw message