xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <grm7...@yahoo.com>
Subject Re: [Fwd: Closure of XMLBeans vote]
Date Wed, 16 Jul 2003 03:47:54 GMT
Thanks Craig, for your detailed response--I had to
read it twice to fully absorb it!  From the
perspective of my concerns, you clearly found my
cynicism unwarranted (to say the least).  FWIW, my -1
is now a +1.

Also, it is evident that many of my remarks on BEA and
its XMLBeans product were painfully classless and
fourth-rate--for those who are or were affiliated with
XMLBeans--please excuse my comments, they weren't
justified given both what I knew and now know about
the product.

<red face/> With tail well between my legs, I'm now
going to run back to the FOP project...  

Glen (who promises to submit a patch to Apache-XML
Beans as penance ;)

Forwarding, Craig McClanahan wrote:

Glen (and others -- presumably someone will moderate
this on to general@xml for me),

Thanks for the vote of confidence in my opinions :-). 
Although, I have to confess I'm by no means an expert
in XML technologies, I'm fair-to-middlen
at Java code, and I'm definitely a customer of XML
technologies of various types (most heavily focused on
reading configuration files in things like
Tomcat and Struts, less so on rendering XML output).

My comments will be mostly philosophical in nature,
because I have not done any large scale investigation
of XmlBeans as a technology; I've just played with the
examples and thought about how it could be used.  It's
pretty intruiging, and I'll comment on that -- but I'd
also like to throw a couple of comments in on the
decision process of how we at Apache accept
projects, and why we might want to or not want to
accept it, or any other project.  As such, I'm
speaking in my "member of the Apache Software
Foundation" and "member of the Jakarta PMC" hats.

On Tue, 15 Jul 2003, Glen Mazza wrote:

> Date: Tue, 15 Jul 2003 11:14:50 -0700 (PDT)
> From: Glen Mazza <grm7793@yahoo.com>
> To: berin@ozemail.com.au, general@xml.apache.org
> Cc: craigmcc@apache.org
> Subject: Re: [Fwd: Closure of XMLBeans vote]
> Berin,
> Sorry, I didn't know that committers--instead of
> the PMC--are able to vote on accepting XMLBeans.  (I
> have not subscribed to xml-apache-general until
> today!)  Let's extend voting a week or two longer,
> get votes from at least 30 or so committers.
> Offhand, I had some concerns about this technology
> which I gave to my FOP team:
>  Hence, my vote is -1.

Quite frankly, I hope you have more backing up a -1
one vote than the three opinions you've expressed

- "looks like a failed technology ..."

- "BEA appears to want to avoid a block eye ..."

- "XmlBeans are dead ..."

without any corroborating evidence.  It's fine to have
opinions about whether a technology is successful or
not, and I'm always amused when people try to ascribe
single-minded motivations to large organizations 
(in my case, anyone who tells you that "Sun thinks
this" or "Sun is doing that" doesn't understand that
40,000 employees don't have a single unified
view on ANYTHING :-).  But where's the beef?

But, even if your presumptions about BEA's motivations
were accurate (and I certainly don't get that
impression from what I've seen so far), is that
relevant to a decision on whether Apache should accept
this technology?  Personally, I don't think so --
what's important to me is that we be willing to host
projects of "interesting" software that can attract a
community of developers.  Beyond interesting to
developers, I also believe that Apache software should
be interesting to users.  (The thing that makes me the
most proud about Struts, for example, is the user
community, not the quality of the code, which is high,
or even the really great group of committers that have
come together to make it so.)

The more important issues you raise, though, are
really the two things that you mention in the middle

* The implied presumption that "XML and XSLT are too
difficult to use and must be masked."  (As a consumer
of XML technologies, I must admit that I agree with
this premise.)

* The idea that different approaches to dealing with
these technologies "may not be compatible with what
XML-Apache is trying to accomplish."

I'm kind of an odd duck -- I actually "get it" how SAX
parsing works, and the kind of power that it can bring
you, and enjoy writing code that works that way (along
with JSP 1.x custom tags, that have the same sort of
design, and even XSLT stylesheets, which I suspect
tends to attract the same sort of mindset :-).  But
trying to explain the inverted control flow
to most Java developers I'm familiar with quickly
causes them to go cross-eyed, and they flee towards
using DOM simply because they can understand it (no
matter how clunky the W3C DOM API is to use).

Therefore, one of the first things we did in Tomcat
land was hide this complexity for the most important
use case where we needed XML -- processing server.xml
and web.xml files in Tomcat.  The initial code was 
called XmlMapper, and it got morphed into the
"digester" utility class in Struts 1.0 when I had the
same need.  Later, it became obvious that this
need was general, and the code was abstracted out into

commons-digester, which tends to be a popular download
from Jakarta for simple use cases of converting XML
data into Java objects.  It was adopted by Tomcat in 

Digester was also one of the inspirations for
commons-betwixt, which does the opposite direction
(Java objects -> XML data), again for relatively
simple use cases.

These libraries are popular, because they are easier
to understand than the underlying XML APIs that Java
exposes through JAXP (i.e. SAX and DOM).
Indeed, the profusion of other innovation around basic
XML processing APIs leads me to believe that it's not
just the Java community that is looking
for things a little easier to use :-).  But using them
comes with a penalty -- you have to hand create the
corresponding bean classes.  

That can be a positive (you may not actually care
about all the content in the document, and this is
particularly true when reading configuration files).
But it can be tedious -- and I've seen quite a few
attempts at doing this kind of class generation
dynamically.  Obviously, someone else seems to
think there is a real need here too.

The second issue (conflict with other projects) speaks
more to the Apache community's purposes of providing
high quality software with active developer
communities.  At least over in Jakarta (which, after
all, now hosts three high quality web application
frameworks:  Struts, Tapestry, and Turbine), we have
not considered alternate solutions in the same
problem space to be a fatal flaw.  You'll see the same
philosophy present in Jakarta Commons -- there isn't
always "one right answer" to every single problem. 
Yes, groups are encouraged to work together instead of
separately (and all three of these frameworks are
already sharing fundamental pieces like the file
upload package from Commons).  In the case of
XmlBeans, how you guys finally want to organize things
(i.e. whether it gets absorbed into some existing
xml.apache.org project that expands scope, or whether
it stays separate) doesn't matter -- whether the
technology itself is compelling and useful, AND can
attract an Apache style developer community, is more
important IMHO.

As I said, though, I'm not all that familiar with the
feelings toward community and internal competition on
the XML side of the house.  I probably should be, so
this exercise is useful to me as a learning experience
in addition to whatever advice I can offer on the
particular subject at hand.

> I'm somewhat troubled by the voting options (listed
> below):  There should be an -1 option to refuse
> XMLBeans into XML-Apache, period, without further
> comment; similar to what already exists for +1.  The
> requirement to "address reservations [in order to 
> make XMLBeans acceptable for inclusion into
XML-Apache]" in
> order to vote a -1 is odd. One should not need to to
> write a white paper on how to redeem XMLBeans in
> to (paradoxically) reject them!
> [  ]  I agree with and support this proposal (+1)
> [  ]  Indifference (-1 < x < +1)
> [  ]  I object and suggest a way to address my
> reservations (-1)
> -1 should be changed to: I reject adding the
> project to XML-Apache.
> This will give a voice to those committers who
> perceive that XML-Apache picking up XMLBeans would
> like General Motors deciding to resume the Edsel
> Ford determined it to be a failure.  For those who
> feel XMLBeans to be dead weight, a distraction that
> XML-Apache doesn't need.

Again speaking from my experience in various Jakarta
projects, we typically offer four choices on votes,
rather than three:

  [ ] +1 -- I agree with the proposal and will support
it (i.e. actively participate in making it happen).

  [ ] +0 -- I agree with the proposal, but can't
            devote any reasons to supporting it.

  [ ] -0 -- I don't agree with the proposal, but I'm
            if the other voters want it.

  [ ] -1 -- I am against this proposal and here is why
            (and you must provide valid reasons).

This seems to give Jakarta folks an appropriate range
of expression to get their point across, and
implicitly commits those who vote +1 to put their time
where their keystrokes are, and really help.  Per the
voting guidelines, a -1 is a veto on "consensus only"
votes (such as accepting a new committer), but it's
just a "no" on majority rules votes (+0 and -0
are both considered abstentions when votes are

The requirement for *valid* reasons grew out of some
painful experiences on a variety of lists, but is
there mainly to avoid someone being able to
throw a monkey wrench in the works solely to be a
jerk, rather than having valid technical concerns. 
That doesn't mean there will never be an argument over
whether a particular concern is "valid" or not (and
there have been some doozies over the years :-), but
it does behoove the person voting -1 to justify their
position.  Of course, that's the only way he or
she would be able to influence the other voters
anyway, but spurious -1 votes with no justification
aren't counted.

Different Jakarta subprojects might apply different
standards to what "valid" means, but the ones I'm
familiar with generally focus on technical
issues, and facts, rather than suppositions and
emotions.  At least that is what we strive for :-).

> But to satisfy the current requirement for voting
> here is one way to address my concerns:  Can we get
> Craig McClanahan's opinion of this technology--he
> basically leads Jakarta Tomcat and Struts and is 
> quite "high up" at Sun.  He has zero affiliation, 
> with BEA.  I have great respect for his integrity
> opinion--and if he endorses this technology, that's
> good enough for me!  OTOH, if he feels XMLBeans to
> "not the best", not something worth investing our
> on, I would continue to recommend XML-Apache passing
> on this technology (i.e., -1).

OK, here's the deal.

* No, I don't have any affiliation with BEA (so my
boss at Sun   can stop worrying :-), although I do
talk to Cliff and several other of the folks that have
been involved in XmlBeans on a variety of topics (such
as the web app framework that BEA chose to utilize
when the implemented page flow support into WebLogic
Workshop this time around :-).

* I don't know enough about XML processing to
"endorse" this, or any other technology, as the
"best".  Indeed, you can count me as a skeptic on
whether there IS such a thing as a best technology for
mapping between XML data and an object oriented API
that covers every use case.  I'm not even sure I
believe that it is technicallly feasible to cover 100%
of the possible  mappings.  But a tool that meets a
large percentage of the use cases can still be
incredibly valuable.

* I do find the XmlBeans approach to be interesting,
and it appeals to my O-O mindset, coupled with a
desire to make Java technologies in general easier for
developers to use.  It's pretty clear from the number
of different approaches that are around (even just for
Java bindings) that a lot of other people find the low
level technologies too difficult to understand and use
-- else why would we be seeing so many different
approaches to fundamental things like a DOM API?

* I don't doubt that there are alternative approaches
already in existence, both at xml.apache.org and
jakarta.apache.org.  I would encourage you NOT to
consider that an automatic reason to vote against. 
Diversity, cross-fertililzation of ideas, and (yes)
even a degree of "competition" can lead to better
projects.  So can collaboration in an expanded project
that might grow to a larger scope than it currently
occupies, if that makes sense (that's for you guys to
decide as part of the incubation process, if XmlBeans
is accepted).

* In earlier discussions (at least the ones I saw on
the Jakarta General and community lists), there were
concerns about licensing and the relative number of
committers from BEA versus other organizations.  Those
sound like they are either resolved or will have the
opportunity to be resolved in the incubator.

* My only concern about XmlBeans, quite frankly, is
one that you did not raise directly -- in the Java
space there is a standard API for binding XML to Java
objects (JAXB), and XmlBeans is not an implementation
of that standard.  That's not necessarily a fatal flaw
(after all, my favorite webapp framework is not a
standard either, although it is being impacted by the
ones I deal with in my "day job" -- Servlet, JSP,
JSTL, and JavaServer Faces), but it is a consideration
to think about.  Indeed, considering some of the loud
voices at Apache, and their opinions on Java standards
and the JCP, this might well be a positive :-).  But
it should be factored in to thinking about the effort
that will be acquired to attract and maintain a
developer community, and a user community, should
XmlBeans be accepted.  The XML community already has
examples of both communities that implement standard
APIs, and those who are innovating on their own.

> Thanks,
> Glen Mazza
> FOP Team

Craig McClanahan

Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

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

View raw message