[x3d-public] Using SysML for SAI

[John Carlson]

An abstract SAI might be something written in SysML and stored in an
appropriate file format.   Would it be appropriate to convert X3DUOM to
SysML?   I don’t know what encoding SysML is written in.   How can we
leverage SysML to produce additional bindings/skeletons?   I’m thinking of
possibly using any SysML tools out there.   I agree our current tools are
sufficient for the declarative tasks in front of us.

John
On Thu, Jun 23, 2022 at 11:39 PM Brutzman, Donald (Don) (CIV) <brutzman at np>
wrote:

> Hi John.  Each programming language has a great variety of features and
> alternatives like you suggest.  It is easy to get overwhelmed by
> overlapping jargon and complexity.  The key qualities needed are clarity
> and re-usability, I think.  This provides us a straight path through all of
> it.
>
>
>
> Our next working group focus will be using X3D4 Architecture for updating
> the abstract API defined by 19775-2 Scene Access Interface (SAI), and then
> further rippling across all our various programming-language
> specifications: Javascript Java Python C C++ C# whatever.  We will also
> update specification documents for file encodings that support JSON (subset
> of Javascript), EXI compression, Turtle, whatever.
>
>
>
> Am expecting this to be pretty repetitive and do-able, which is good.
> Thus an author’s X3D4 model can be consistent and clearly understandable
> and equivalently re-usable across all of these programming dialects and
> file formats.  Then gurus and plain folks can just re-use interactive X3D
> graphics models, which is what everyone really wants.
>
>
>
> Classic stumbling blocks like “this programming language is better than
> that one” are perhaps simply boring, from a shared group perspective.
> Let’s make the best of each world available and easy, however each set of
> experts want to do it.
>
>
>
> Onward we go.  However you like to have fun… have fun with X3D!  8)
>
>
>
> all the best, Don
>
> --
>
> Don Brutzman  Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu
>
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
> +1.831.656.2149
>
> X3D graphics, virtual worlds, Navy robotics https://
> faculty.nps.edu/brutzman
>
>
>
> *From:* x3d-public <x3d-public-bounces at web3d.org> *On Behalf Of *John
> Carlson
> *Sent:* Thursday, June 23, 2022 7:03 PM
> *To:* X3D Graphics public mailing list <x3d-public at web3d.org>
> *Subject:* [x3d-public] Potentially important work:
> Java/Python/JavaScript encoding parsers
>
>
>
> We all know about SAI bindings and X3D encodings.
>
>
>
> Can I suggest an alternative?  Has anyone considered limited parsers for
> X3D Java/Python/JavaScript SAI examples?   That is, don’t use a full
> parser/compiler to read examples, use a limited one to reduce the attack
> surface of SAI examples.
>
>
>
> I believe there is precedent for this.   In the early 1990’s Tim Sullivan
> of Independence technologies devised a way to either compile or interpret
> specialized apps, like CRUD forms.   It was called iScreen, and one could
> use a variety of toolkits, SunView, XView and Motif to write cross-platform
> apps.   I took the idea and we developed a programming language that could
> be written and read from flat files and C++ variables.   We had a primitive
> parser, or you could compile the program with a full blown C++ parser and
> link it to a virtual machine.   Today, Cameron Browne is using a “class
> grammar” in his Ludii project.
>
>
>
> The point is to treat X3D examples half like programs and half like
> program encodings.   One should be able to “compile” an encoding example to
> native  code.   This is probably a lot like JIT compiling.
>
>
>
> Does X3D have a native JIT compiler?  Java?   Can we improve on code we
> produce from X3dToJava.xslt to do something even faster?   Can we strip
> away the object model, or compile the object model to native code?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220624/226d33a4/attachment.html>