[x3d-public] Using SysML for SAI

[John Carlson]

It just occurred to me that SysML might be an opaque, unreadable file
format, and thus hard to verify/validate.  I don't know if that's the
case.  Anyone know?

Thanks!

John

On Fri, Jun 24, 2022 at 10:16 AM John Carlson <yottzumm at gmail.com> wrote:

> 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/634912cd/attachment-0001.html>