Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of sandymac@gmail.com designates
 64.233.166.183 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=FJ6O97DsvwdDwX4rpMZnRQGpuaFdp2trXjoIVr6VsA/ABL6c6oksLlIefnSQmr4gnC15fbQRD+7hI05MbCpdLD6lstmAn72AUgQuy4rZim/RXEuLEhz7l0FBqq37bIIb8PqARIekkzLn+ua/ygE6NYqS3alKttzzO49VK3ymqHQ=
Message-ID: <6bde122b0604181930k7d654ed3id13a58b765cf788c@mail.gmail.com>
Date: Tue, 18 Apr 2006 22:30:20 -0400
From: "Sandy McArthur" <sandymac@apache.org>
Sender: sandymac@gmail.com
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [all][SCXML] Whats in the name ...
In-Reply-To: <31cc37360604171535m43ac957s1a08fe13ebd02465@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <ce1f2ea80604171520i15109f25n666725526b191fb2@mail.gmail.com>
	 <31cc37360604171535m43ac957s1a08fe13ebd02465@mail.gmail.com>

How about a long name and short name? URLs, packages, email prefixes,
etc use "scxml" but page titles, readme.txt, articles, or other text
use an expanded name of "State Chart XML".

On 4/17/06, Henri Yandell <flamefew@gmail.com> wrote:
> Personally, I think StateChartXML is a good name, but am not bothered
> by SCXML as long as the website explains what the acronym means.
>
> Hen
>
> 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
>
>


--
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

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