FW: SCXML - Haxe language implementation

From: Zjnue Brzavi [mailto:zjnue.brzavi@googlemail.com]
Sent: Wednesday, May 08, 2013 11:05 AM
To: Jim Barnett
Subject: Re: SCXML - Haxe language implementation

Hi,

Just a quick note.
The tests are proving to be invaluable for filling in the gaps in my understanding / routines.
There are however some tests that appear to have html instead of template content.
Currently, they are:

        // these tests currently have invalid content
        var ignore = [
            "496.txml",
            "577.txml",
            "test354.txml",
            "test446.txml",
            "test459.txml",
            "test483.txml",
            "test513.txml",
        ];
All the best,
Zjnue


On Wed, May 8, 2013 at 1:06 AM, Zjnue Brzavi <zjnue.brzavi@googlemail.com<mailto:zjnue.brzavi@googlemail.com>> wrote:
Hi,

Please excuse the small delay.
I feel honoured to hear back from you and, not only so soon, but already seeing the changes we talked about implemented - simply fantastic!
While on that subject, here are 3 more minor points:
- addAncestorsToEnter should be addAncestorStatesToEnter
- procedure computeExitSet(enabledTransitions, statesToExit) should be procedure computeExitSet(enabledTransitions)   ...where enabledTransitions is a List
- given the above, calls like computeExitSet(t), should be computeExitSet([t])

Thank you for your comments.    As far as I am personally concerned, you are free to include any parts of the documents and test that you wish.  The W3C does make the following statement about the use of its documents http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231 , but I doubt if they will object if you don't do exactly what they specify.    As long as you acknowledge _somewhere_ that you have borrowed from the specification and the tests, I think that things will be fine.

Thank you, I've not had much personal dealings with the W3C before, but it always did come across as a very friendly organisation with the best of intentions. I did also discover that link eventually and decided it is probably best to leave code comments until the spec is finalized. Then dress it up nicely for HTML formatted code hints in IDEs etc. I may decide to include the tests before then, so will be sure to leave the appropriate comments, to my best efforts.


I would warn you that the test files .txml and .xsl may change as we get further in the process.  If you want to be sure to always have the most up-to-date version, it's probably best to link to the original files.  If you decide to make a copy, it would be good to check occasionally to see if there are any changes.

Thank you for the warning. I will probably provide an executable for updating the tests easily, but include them in the repository, to pique interest of people not necessarily familiar with SCXML yet. Having examples always seems to help. In fact, the Haxe community as quite a strong and innovative constituent interested in building UIs. There is also a strong interest in "live" environments.
I've recently discovered these interesting bodies of W3 work:
http://www.w3.org/2005/Incubator/model-based-ui/XGR-mbui-20100504/
http://www.w3.org/TR/mmi-arch/
I'm very excited to read about research into such adaptive interfaces, as they marry well with my own views.
Are you aware of existing efforts incorporating SCXML with UI and other interface development?
I've actually been looking out for good SCXML editors too and have gathered some research material on HSM layouts.
It would be more effective not to re-invent wheels, so again, if you are aware of any (quite open) efforts in this direction, I'd be very interested to hear.
So far I've explored the following:

Kieler  (seems nice, locked into a EPL license though)
http://www.informatik.uni-kiel.de/rtsys/kieler/
http://rtsys.informatik.uni-kiel.de/confluence/display/KIELER/Home

SCXMLGUI  (appeared to be a bit broken in my tests, nice developer, gave permission for a MIT port)
http://code.google.com/p/scxmlgui/

Yakindu  (only discovered recently. while strictly a statechart editor and not scxml, perhaps there is a good path between the two?)
http://code.google.com/a/eclipselabs.org/p/yakindu/
http://rtsys.informatik.uni-kiel.de/confluence/display/KIELER/How+to+open+YAKINDU-SCCharts+Editor
I've done a Canviz [1] port to Haxe already and have some dot generated from my hscxml repo [2], so until I find better port candidates (MIT license or more permissive), I'll try to make a lightweight editor using Graphviz in the background.


The best way to be included in the list of SCXML implementations is to submit an implementation report when we call for them.  This will be in a few months and there will be an announcement on the public list.   As part of the publication of the specification in its final form, we include a link to the full Implementation Report, and that includes the results from all implementations that submitted a report.  You can also include a 'testimonial' in the report in which you can say what you are using SCXML for and why you find it useful.
Fantastic, thank you. I will look out for the IR call and it would be a pleasure to provide a testimonial.

Also, I wonder if there is interest in specifying other potential Data Models [3]?
For the Haxe community, there will be 2 that I'll implement: (partly done)
1. HScriptModel
2. SelectHXmlModel
HScriptModel offers a very familiar "live" ECMA-style scripting environment, in using hscript [4]. From what I gather, it seems ideal for the purposes of SCXML, in that it provides familiar ECMA-style syntax, while also providing a nice execution sandbox, something I gather the ECMAScript Model struggles with.
Oh, on this note, I'm not sure I understood how the models should expose themselves to the Interpreter.
Is there a documented API for this integration?

Not researched SelectHXml [5] well yet, but from a quick look this seems like a good choice for Haxe in the absence of a XPath2 library. There is a XPath1 library tough, but a little bloated.

As mentioned, Haxe is in the process of becoming even more attractive in terms of language power and added targets. Dave Raggett from the W3C was around the community at a time when the XML support for Flash was not particularly good. We joined efforts in a proposal to to help fix it and the proposal did get accepted eventually. Haxe Xml is not yet fully conformant to W3C XML, but especially now, with the advent of abstract types, type overloading, etc, it should be very possible to build a fully conformant XML type, which works well across targets. Haxe Xml already does, but does not include the full specification, as alluded to.
Please excuse the run-away pitch, but I sincerely hope to find interest in Haxe from the W3C community, if not Dave, someone else.
The goals of empowering users and harmonizing across environments seem very central to both ecosystems.
Ok, pitch over for now :)

I will check on the comments you make in [2] and update the spec accordingly.
Wonderful, thank you so much. Open source collaboration strikes again!
Best wishes,

Zjnue
BTW, any ideas for this? I'm considering participation.
http://lists.w3.org/Archives/Public/www-voice/2013AprJun/0092.html

[1] http://code.google.com/p/canviz/
[2] https://github.com/zjnue/hscxml/blob/master/src/hsm/scxml/tools/DrawTools.hx
[3] https://github.com/zjnue/hscxml/blob/master/src/hsm/scxml/Model.hx
[4] http://code.google.com/p/hscript/
[5] http://code.google.com/p/selecthxml/



Best wishes,

Jim Barnett



From: Zjnue Brzavi [mailto:zjnue.brzavi@googlemail.com<mailto:zjnue.brzavi@googlemail.com>]
Sent: Saturday, May 04, 2013 8:16 PM
To: Jim Barnett
Subject: SCXML - Haxe language implementation



Dear Mr Barnett,

Firstly, I would like to extend my sincere gratitude for all the efforts that have lead to this most exciting milestone of an imminent SCXML 1.0 release - congratulations!



I've been following the SCXML evolution on/of since 2008/2009.

Mostly playing around with the "Algorithm for SCXML Interpretation".

Recently, I've decided to return to the subject more seriously and have only yesterday caught light of the links to these new IRP pages:
http://www.w3.org/Voice/2013/scxml-irp/SCXML.htm
http://www.w3.org/Voice/2013/scxml-irp/SCXML_Diff.htm
http://www.w3.org/Voice/2013/scxml-irp/

I've just made some updates to my repository [1] and have a few questions / comments if you don't mind?

Feedback on Algorithm for SCXML Interpretation



It seems I've missed the final date for feedback on the new draft, but I'll include some comments [2] here quickly, in case of interest. I did search the www-voice list for similar feedback, but did not notice some of the points. ( Most can also be found by a search for "report:" in Interp.hx [3] )



Questions around spec comment inclusions in code



In order to aid my coding, I've copied some spec text throughout my Interp.hx [3] class. I apologise if this has already caused problems, but the intent was merely to help with swift and accurate coding. Is it in order to leave it there? Shall I include a separate license for the comments? Any other suggestions? Perhaps I should also ask if I may save a concrete copy of a spec draft page for inclusion in a doc folder or such? Of course, the version saved would be the one that is coded against.

Questions around test suite inclusion

In a similar vain, is it permissible to include the test suite files (*.txml, *.xsl, etc) in my repository?

Can I save a copy of the accompanying website [4] for convenient reference? ..and even perhaps modify it slightly to change all *.txml file links to point to a single folder?

If I include a README.md file in a test folder and state the license conditions in [4] again, would that be sufficient? By the way, the link pointing to the test zip file (http://www.w3.org/Voice/2013/scxml-irp/scxml10-irp-20100715.zip) seems broken, but I've now downloaded each file separately.



Comments around my Haxe implementation

I would very much like to see how fast and how far I can get in terms of satisfying the tests with my implementation (I know there is a way to go...).

I've not yet added a LICENSE file to my repo, but I plan to make it very permissible, in order to make the technology very accessible. For similar accessibility / learning considerations I've tried to match the spec quite literally with my coding style. This can be further improved.

Also, I would like to share with you that the Haxe [5] is a wonderful multi-platform language and happens to make ready for a Haxe 3.0 RC2 release later today (Sunday) - and a full 3.0 release later this month. It can target all Flash versions, JavaScript, PHP, Neko, C++, Java, C# and there are various others in development, like Rust, ObjC, Python, etc.

As the interpretation algorithm is written in pure Haxe (where it does not integrate with specific environments - as with some external integration), it should be a hugely portable one, so I hope it becomes a familiar and welcome citizen in the SCXML world.

On that note, I wonder if there are particular registrations I should fill in for inclusion on "implementation lists", programmes and the like?



I realise there is still a lot of work to do for me, but I hope you see my reasons for this encompassing / verbose email. Oh, I've registered for the www-voice list today only, so won't make a habit of direct emails - apologies if it caused inconvenience.



Best regards,

Zjnue



[1]
https://github.com/zjnue/hscxml/tree/wd20130424

[2]

* whlie function intersection is stated as required for OrderedSet, it is never actually used in code

* function selectEventlessTransitions refers to another called filterPreempted, which is never declared

* there are 2 separate and different declarations for removeConflictingTransitions(enabledTransitions)

* there is a typo where isDescendent should be isDescendant

* function addAncestorStatesToEnter has in its body a call to addStatesToEnter, which is not declared. should that call be to addDescendentStatesToEnter instead?

* in order to get an old example working, I've had to modify getProperAncestors to include state1 if it is a scxml node. I've not spent much time on it, but a quick mention perhaps

[3]
https://github.com/zjnue/hscxml/blob/wd20130424/src/hsm/scxml/Interp.hx

[4]
http://www.w3.org/Voice/2013/scxml-irp/

[5]
http://haxe.org/