xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Boag/CAM/Lotus" <Scott_B...@lotus.com>
Subject Re: [spinnaker] Announce
Date Tue, 11 Jul 2000 03:13:33 GMT

James Duncan Davidson <james.davidson@eng.sun.com> wrote:
> Yes, I know. I've been pushing on them. But they are in a different
division
> than I am. My range of influence is limited.
...
> But now you are talking Sun vs. IBM again. Don't lump me in with what
> they've done.
...
> except for the fact that I'm
> from Sun, I've got an eng.sun.com address that I'm posting with, and you
> hate me for that.

No.  It's not Sun vs. IBM, it's not directed at you personally nor at Sun
as an entity, I don't hate you, and please don't lump *me* in with a crowd.
My problem is with a general pattern of revolution for whatever reason vs.
good, open design discussion... I feel revolution should only be used as a
last resort.  I feel the same way about this in a single company in a
single building, as with a distributed open source environment.  Call me
naive, but I would like to think of xml.apache.org as my extended team with
whom I'm working towards a common goal.  Frankly, I like collaboration
better than competition (I'm just a wimp, I guess...)

There is no question that both the Xerces and Xalan code have issues, and
need improvement -- design decisions are hell, and usually have flaws and
tradeoffs, and are often based on the issues of the day.  If you have been
having discussions with Pogue or whomever in the Xerces team, your cause
would probably be better served having these discussions through the public
mailing lists.  I, for one, haven't seen these discussions.

So let's just talk about what needs improving, and what the best way to go
about that would be (as you say, you did kick off some of these discussions
on the Xerces list).  Too complex you say?  Let's talk about why, the
tradeoff's of features, compatibility, performance, etc., and steer clear
of dramatic project announcements (that, on top of everything else, make
their way into the press).  I love discussions that go something like...
"what good is that OpMap doing instead of expression classes?  Why the hell
don't you just use a java-yacc equivalent for the XPath parser?  What are
the tradeoffs using a compiled approach?  Your handling of xml:stylesheet
sucks... here's some code which I think does the job better".  I dislike
discussions that go something like "Your project is too big and complex, so
I want to start over."

> However, I
> can't control what they do.

I don't expect you to.  Please forgive me if you feel attacked.  It's the
actions, not the affiliation of the players that bother's me.  I learned
their email addresses a week or so ago, and now it's up to me (or anyone
who is interested in Xalan and XSLT) to send them a note.  In the PMC
discussions, I was only looking to you because you brought the issue up and
I did not have any other contact.  (However... any prodding on your part
would be appreciated... :-)  )

The XSLT Processor and the XML Parser are two separate issues and have
different players.  I only brought it up because it was mentioned, and
there are direct parallels.  If the Translets announcement had been made by
another company, I don't think it would have changed my note much.

> Note that Xalan 2.0 is essentially a complete rewrite

It's an evolutionary rewrite.  There are still parts of Xalan 1.0 in there,
like the DTM.  By the time we finish, it may well be a complete rewrite.
But note that the Xalan processor was in an earlier state than Xerces when
submitted (the ink was barely dry on the XSLT spec when submission
occured... and, hell, we're in a learning process still, and will be for a
while).  In any case, I don't think the question is how much code should be
rewritten... the questions are of detailed design.  I don't care if Xalan
or Xerces have complete rewrites five times more... the issue are, what's
the best approaches and tradeoffs?  I think that can best be figured out as
a collective Apache "team", rather than having factions.  I believe, if
people are willing, this can be done without an authority figure or
manager.  The trick is to forget the bullshit, and just listen to the
technical issues, and brainstorm cool ideas.

> Xerces hasn't had a publically discussed, wide open NG workspace for talk
> about a new parser until now.
...
> Ok, so I sent out a message with a list of goals and a proposed way of
> getting there. You'll notice that I started a design discussion yesterday
on
> xerces-j-dev.

So this "[spinnaker] Announce" thread is probably wasting cycles, and I
hope we can call peace (I probably shouldn't be continuing the discussion
with this note).  Why don't we forget "spinnaker" or whatever, and do the
"clean room" discussion (as my friend Stefano puts it) about what you and
other's would like to see in a parser that contains *constructive* design
suggestions.  Xalan 2.0 did not start out as a complete rewrite... we
simply put up a clean slate for the design.  Code is only the final
manifestation of design ideas, and is irrelevant in some sense.  It's fine
if the discussions get heated, but, please, let's all try and stay at the
table for a while, and keep the discussions detailed, technical, and
practical.

-scott





Mime
View raw message