Re: SCXML Extensions for graphical description

Hello guys,

I identify two scenarios here:
1)You are using a vendor specific graphic tool for
UML.


You have XMI and more specifically EMX which is
Rational propietary modeler xml language (XMI version
in any case). You have as another example VDX from
Microsoft Visio.

Both of the above describe graphics while still they
are xml.

SCXML is a language to describe Harel State Machines
which are specified as part of UML2 as Gilman is
suggesting. XMI can be used to represent UML so the
only thing you need to do is create the necessary
stylesheet (XSLT) to convert from scxml to specific
XMI that can later be rendered by specific graphic
tools. Another stylesheet should be specified for the
reverse process because there are times in which you
want to go from graphics to scxml as well as the other
way around having that way complete round trip forward
and reverse angineering.

2)You want or would like w3c to specify a graphical
language for UML.

If w3c decides to put presentation and data all
together it will be great because being of public
domain plugins for eclipse will appear quick enough in
the market.


However there are some vendor standards that are like
EMX from Rational and there are a lot of people
working with Rational so another approach is just to
write specific stylesheets as I said.

Thanks!
--- Al Gilman <Alfred.S.Gilman@IEEE.org> wrote:

> 
> At 5:51 PM -0700 5/29/06,
> <jamesmsort-third@yahoo.com> wrote:
> >Hello,
> >
> >I was reviewing the document for state machine XML
> ( 
>
><http://www.w3.org/TR/2006/WD-scxml-20060124/>http://www.w3.org/TR/2006/WD-scxml-20060124
> 
> >).
> >
> >I'm working on a translation script that will
> import/export between 
> >SCXML and a popular state machine tool.  The task
> is complicated by 
> >the lack of graphical attributes in the SCXML
> schema.
> >
> >I think that most users would want to display their
> state machines 
> >graphically for a number of reasons:
> >
> >1.  Creation process
> >2.  Peer reviews
> >3.  Documentation
> >
> >I more interested in reason #1.  I have no desire
> to create my state 
> >machines by typing in text by hand.  I'd rather use
> one of the many 
> >graphical tools for creating and simulating state
> machines. 
> >However, I'm interested in converting my state
> machines into a 
> >tool-independent format.
> >
> >States and transitions require graphical
> information including:
> >
> >1.  Origin
> >2.  Dimension (states only)
> >3.  Termination (transitions only)
> >
> >I'm considering two options for my SCXML conversion
> tool:
> >
> >1.  Modification of the SCXML schema to include
> graphical attributes
> 
> As in, join the SCXML and SVG schemas?
> 
> >2.  Inclusion of well formatted comments that would
> detail the 
> >graphical information.
> 
> You could do this using <metadata> and an RDF
> transcription of your graphic
> ontology.
> 
> Of course there is the reverse approach, where you
> bind the state 
> chart semantics
> in metadata in an SVG graphic.
> 
> Your 'comments' are not 'well formatted' unless they
> come with a schema binding
> to something stable.
> 
> >Do you have any recommendations on how to proceed?
> 
> [fools rush in...]
> 
> 1. Does the tool you want to support already support
> UML state
> charts? Would they meet your graphic needs?
> Review the close relationship between SCXML and UML
> state charts
> before re-inventing anything. Work the
> graphics-unaware SCXML dumper
> first.
> 
> 2. Embed the graphic properties in the SCXML tree
> rather than vice
> versa. It's harder to get there but your state
> charts have such
> strong network semantics that starting with drawing
> instructions
> leaves too much to the imagination.  But you new
> that.
> 
> YMMV
> 
> Al
> 
> >
> >Is there a future extension to SCXML in the near
> future that 
> >includes graphical information?
> >
> >Thank you in advance for your time.
> >
> >Kind Regards,
> >
> >Jim
> 
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Received on Wednesday, 31 May 2006 11:57:55 UTC