xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edwin Goei" <Edwin.G...@eng.sun.com>
Subject Re: [spinnaker] Announce
Date Tue, 11 Jul 2000 20:08:07 GMT

----- Original Message -----
From: "Scott Boag/CAM/Lotus" <Scott_Boag@lotus.com>
To: <general@xml.apache.org>
Sent: Monday, July 10, 2000 8:13 PM
Subject: Re: [spinnaker] Announce


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

I personally don't care what it's called, but what I would like to see is a
new design that is discussed on the list.  I also think it should be in a
different tree so it can be developed independently of the current code.
Mime
View raw message