shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: [dialog] Name attribute best practice
Date Fri, 25 Aug 2006 19:06:53 GMT
On 8/25/06, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>
> On 8/25/06, Craig McClanahan <craigmcc@apache.org> wrote:
> > On 8/25/06, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> > >
> > > I would like to propose a best practice for the name attribute used in
> > > various bits of the XML vocabulary for Shale dialogs that recommends
> > > restricting these to alphanumeric characters (no spaces etc.)
> >
> >
> > I suppose there's a technical reason for this ... I really like the
> > readability of these if we can keep them and it was why I chose "name"
> > instead of "id' for that attribute in the first place.
> >
> <snip/>
>
> Yes, the state IDs are meant to be IDREFs in space separated lists on
> transition targets when the SCXML <parallel> element is used, where it
> will be possible to have more than one transition target, as long as
> the targets belong to the regions of the same parallel.
>
> Ofcourse, when using a space separated list, having spaces in
> individual tokens will throw a wrench in the works.


Yah, that makes sense.  Go ahead and do the patch, and I'll apply it.

-Rahul


Craig

> Craig
> >
> > Commons SCXML v0.5 is accomodating in that it will allow spaces for
> > > state IDs (which is what the name attribute maps to) but there are
> > > good reasons why we will shy away from this in some future release be
> > > it at the cost of some legibility (driven by changes to that spec
> > > draft).
> > >
> > > I will produce a patch over the weekend such that the usecase
> > > application follows this best practice (ofcourse, unless someone has a
> > > good reason why we can't do without spaces here).
> > >
> > > -Rahul
> > >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message