[x3d-public] motivations and potential renaming of OM4X3D as X3D Unified Object Model (X3DUOM)

[Don Brutzman]

Michalis, this work looks really excellent.  It is interesting to see that you have diligently implemented the X3D node types as part of your hierarchy.

Similar design patterns for autocreation of node signatures are also interesting to observe. Going even further, conceivably a simple stylesheet might parse the XML object model X3DObjectModel-3.3.xml
	http://www.web3d.org/specifications/X3DObjectModel-3.3.xml

... to create corresponding component definitions like those found in
	https://github.com/castle-engine/castle-engine/tree/master/src/x3d/nodes_specification/components

... which might be a good automated doublecheck diff for you to verify correctness and completeness.  This might also simplify continued addition of additional v3.3 and future v4 nodes.

Looks like you have gone in the other direction too, for strong typing of simple non-node typed values.  For example, an excerpt

===============================================================================
	https://castle-engine.sourceforge.io/manual_scene.php#section_transform

	Material := TMaterialNode.Create;
	{ Yellow (we could have also used YellowRGB constant from CastleColors unit) }
	Material.DiffuseColor := Vector3Single(1, 1, 0);
	Material.Transparency := 0.75;

	Appearance := TAppearanceNode.Create;
	Appearance.Material := Material;

	Box1 := TBoxNode.Create('box_1_geometry');
	Box1.Size := Vector3Single(0.5, WallHeight, RoadBox.Sizes[2]);
===============================================================================

shows typed arrays.  The SAI language bindings go even further beyond direct assignment of fields by providing typed get/set accessor methods.

On 8/19/2017 9:19 AM, Michalis Kamburelis wrote:
> 2017-08-19 16:11 GMT+02:00 Don Brutzman <brutzman at nps.edu>:
>> f. Development of programming-language APIs for X3D using JavaScript, Java,
>> C, C++, C# and Python can continue to proceed in parallel.
> 
> My Castle Game Engine ( https://castle-engine.sourceforge.io/ ) is
> also providing API to manipulate X3D scene graph using Object Pascal
> :)
> 
> An easy example how to build X3D scene graph using Object Pascal code
> is e.g. in the manual chapter "Transform, animate, duplicate, build a
> scene" https://castle-engine.sourceforge.io/manual_scene.php , scroll
> to section "Building and editing the scene". You can create and edit
> the X3D scene graph before or during the game, that's how my game
> engine exposes the full strength of X3D :)
> 
> The documentation under
> https://castle-engine.sourceforge.io/vrml_x3d.php lists of all the
> supported nodes, with links to X3D specification and to our Pascal API
> documentation, e.g. click on "Transform" and it's"(API reference)" in
> https://castle-engine.sourceforge.io/x3d_implementation_grouping.php .
> 
> BTW, the API of nodes is partially generated automatically. We have a
> simple text representation of nodes in
> https://github.com/castle-engine/castle-engine/tree/master/src/x3d/nodes_specification/components
> , see e.g. "Grouping" mode on
> https://github.com/castle-engine/castle-engine/blob/master/src/x3d/nodes_specification/components/Grouping.txt
> . This is parsed and automatically converted to a (partial) Pascal
> code defining this node by a program x3d-nodes-to-pascal in this
> repository.
> 
> Regards,
> Michalis
Of course your API is closely aligned with your rendering by your game engine. So it isn't clear if separating out a pure SAI-based library for use by other ObjectPascal programs really makes sense.  But it is a possibility, if even-more-general ObjectPascal usage became desirable.

Looking at Wikipedia for ObjectPascal, it doesn't look like there is any ISO effort underway.  So adding another X3D ISO language binding may or may not make formal sense.  Even so, it is always good to think about how various programming styles compare.  We can also keep track of similar, related progress with programmatic X3D.

	https://en.wikipedia.org/wiki/Object_Pascal

Am also happy to see that you have Distributed Interactive Simulation (DIS) bindings specified.  We will probably revisit/re-open the Open-DIS work this fall, it would be great to test interoperability if you like.

BTW am also expecting that we might try to align X3DJSAIL java library with Matlab later this year, using the mechanisms already provided in that language.

	https://www.mathworks.com/help/matlab/using-java-libraries-in-matlab.html

Looking even further ahead: since Octave is an open-source C++/C library designed to match Matlab syntax, maybe similar approaches might be someday pursued using a C++ SAI Library.  Or use Java X3DJSAIL bindings.  And so on...

	https://www.gnu.org/software/octave/about.html
	https://www.gnu.org/software/octave/doc/interpreter/Java-Interface.html

So it is probably reasonable to expect that as we get a X3D Unified Object Model well specified and well implemented, we can expect that other language and application usages of X3D to proliferate in corresponding fashion.  Consolidated, coherent baseline design will certainly help such work.

Programmatic (application or server-side) X3D will be an excellent activity to encourage and compare, with mutual benefit all around.  Looking forward to continued progress together!

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 http://faculty.nps.edu/brutzman