commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject RE: [all][SCXML] Whats in the name ...
Date Thu, 20 Apr 2006 13:49:01 GMT
Shouldn't we throw in the obligatory 'J'?  

JSCXML?


-----Original Message-----
From: Niall Pemberton [mailto:niall.pemberton@gmail.com] 
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 <rahul.akolkar@gmail.com> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message