Shouldn't we throw in the obligatory 'J'? JSCXML?
-----Original Message----- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 19, 2006 10:26 PM To: Jakarta Commons Developers List Subject: Re: [all][SCXML] Whats in the name ... +1 for keeping SCXML. Firstly since Rahul has done the work then I don't think we should try to impose a name. Secondly, since it is an implementation of a spec, then using that in its names looks like a good idea to me. Lastly if we want a component with a generic name like "state", "statechart", etc - then IMO we need someone to come forward with some generic "state", "statechart" etc. code. As no-one seems to proposing/offering that - then lets stick with the actual concrete thing we have - which is Rahul's SCXML. Niall On 4/17/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > A fairly random stringing on my thoughts on the topic ... > > Since there was talk about whether SCXML makes a good name for the > component, its only appropriate that I list some reasons. State means > little to me (or better, means so many things that is becomes > extremely fuzzy). A statechart, to me, is a graphical entity, tied to > the modeling layer, and in general does not cleanly tie in to any > execution environment. There is lot of state chart theory around, many > flavors exist with minor semantic deltas (UML 1.5/2.0, STATEMATE, > RHAPSODY, and now SCXML). I think nothing defines scope and semantics > better for this component that clarifying that we use SCXML semantics > (by default) via the component name. We shouldn't lose this clarity > only to have to struggle to regain it via numerous clarifications on > the mailing lists each time a related question is raised. We need an > oracle. We have a bunch of smart folks from a leading standards > organization giving us just that. Maybe some years down the line, the > abbreviation SCXML may become more commonly known. > > If all of us here drop this component on the floor and walk away from > it today, I believe that after any arbitrary amount of time, someone > with a beginner level understanding of Java and XML can pick it up, > hold the SCXML document from the W3C by its side, and atleast figure > out if the thing is doing what it is supposed to do -- and if not, > attempt to correct it. Also, JCP, RFE and W3C standard driven projects > have an easier time managing their scope. > > No user has complained about the component name, mailing list prefix > used etc. (though having injected this debate into the mix, this may > now come up frequently). StateChartXML is a decent suggestion, though > I'm personally not motivated enough to make the change. I will be > breaking some user code before the first RC (I'll post a note to the > user list when that happens), but changing Java package names will > probably cause more confusion that is warranted, so those are best > retained. > > Finally, recounting from personal experience, when I came to Commons, > I knew what I was looking for (Digester). I didn't know what Jelly > was, what JEXL stood for, what betwixt was getting in between, what > configuration was configuring nor what latka did. Then one day, I read > the descriptions. > > -Rahul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
