JDOM in Apache (was Re: xml.apache.org charter proposal)

[Sc...@lotus.com]

"Brett McLaughlin" <br...@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.

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/utils/DTM.java
http://xml.apache.org/websrc/cvsweb.cgi/xml-xalan/java/src/org/apache/xml/utils/DTMFilter.java
http://xml.apache.org/websrc/cvsweb.cgi/xml-xalan/java/src/org/apache/xml/utils/DTMIterator.java
http://xml.apache.org/websrc/cvsweb.cgi/xml-xalan/java/src/org/apache/xml/utils/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.

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.

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.

-scott






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

Re: JDOM in Apache (was Re: xml.apache.org charter proposal)

[Ted Leung <tw...@sauria.com>]

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


>
> "Brett McLaughlin" <br...@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