commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <flame...@gmail.com>
Subject Re: [all][SCXML] Whats in the name ...
Date Wed, 19 Apr 2006 03:18:51 GMT
I pondered the same idea - however the important ones to get decided
up front are the short names you mention below. The longer ones can be
covered by making sure that the acronym is spelt correctly on the
first usage each time on said articles, page titles etc. So the
suggestion becomes a null-op I think as it's really a description of
how to deal with acronyms in text.

Hen

On 4/18/06, Sandy McArthur <sandymac@apache.org> wrote:
> 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
>
>

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