You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rahul Akolkar <ra...@gmail.com> on 2006/04/18 00:20:06 UTC
[all][SCXML] Whats in the name ...
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
Re: [all][SCXML] Whats in the name ...
Posted by Phil Steitz <ph...@gmail.com>.
I agree with the arguments that Rahul presents below for keeping the
name [SCXML].
Phil
On 4/17/06, Rahul Akolkar <ra...@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
Re: [all][SCXML] Whats in the name ...
Posted by Rahul Akolkar <ra...@gmail.com>.
Thanks for the feedback on this thread. I should also point out that
credit is due to anyone who is listed on the component proposal, team
list, anyone who voted for or (mildly) against it, the users and so
on.
It seems atleast some of us support the current name, so my inertia
will hold and I'll proceed with the svn / website move etc. this
weekend, unless there are other developments on this thread by then.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all][SCXML] Whats in the name ...
Posted by Martin Cooper <ma...@apache.org>.
On 4/19/06, Niall Pemberton <ni...@gmail.com> wrote:
>
> +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.
What Niall said. +1.
--
Martin Cooper
Niall
>
> On 4/17/06, Rahul Akolkar <ra...@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
>
>
Re: [all][SCXML] Whats in the name ...
Posted by Rahul Akolkar <ra...@gmail.com>.
</thread>
I will complete the tasks associated with sandbox graduation later in the day.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all][SCXML] Whats in the name ...
Posted by Rahul Akolkar <ra...@gmail.com>.
On 4/20/06, James Carman <ja...@carmanconsulting.com> wrote:
> I was half kidding, but now that I think about it, it might not be such a
> bad idea. The specification is called SCXML. The Apache implementation of
> it should be distinguished in some way, IMHO. I mean, the Apache web server
> isn't just called HTTP (although, the daemon is called httpd...hmmmmm). :-)
>
<snip/>
But we already can distinguish it.
* EL / Commons EL
* SCXML / Commons SCXML
If you look through the user archives, the prefix Commons
unambiguously qualifies the implementation. The advantage ofcourse, is
if you google "scxml", the first hits are the W3C document, followed
by the Commons impl. Priceless, IMO. Also, personally I dislike J*,
*4J what have you.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [all][SCXML] Whats in the name ...
Posted by James Carman <ja...@carmanconsulting.com>.
I was half kidding, but now that I think about it, it might not be such a
bad idea. The specification is called SCXML. The Apache implementation of
it should be distinguished in some way, IMHO. I mean, the Apache web server
isn't just called HTTP (although, the daemon is called httpd...hmmmmm). :-)
-----Original Message-----
From: James Carman [mailto:james@carmanconsulting.com]
Sent: Thursday, April 20, 2006 9:49 AM
To: 'Jakarta Commons Developers List'
Subject: RE: [all][SCXML] Whats in the name ...
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 <ra...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [all][SCXML] Whats in the name ...
Posted by James Carman <ja...@carmanconsulting.com>.
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 <ra...@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
Re: [all][SCXML] Whats in the name ...
Posted by Niall Pemberton <ni...@gmail.com>.
+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 <ra...@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
Re: [all][SCXML] Whats in the name ...
Posted by Henri Yandell <fl...@gmail.com>.
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 <sa...@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 <fl...@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 <ra...@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
Re: [all][SCXML] Whats in the name ...
Posted by Sandy McArthur <sa...@apache.org>.
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 <fl...@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 <ra...@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
Re: [all][SCXML] Whats in the name ...
Posted by Henri Yandell <fl...@gmail.com>.
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 <ra...@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