[x3d-public] setUSE in X3DJSAIL. Impact on X3DJSONLD.

[Don Brutzman]

On 7/20/2017 3:02 PM, Andreas Plesch wrote:
> 
> 
> On Thu, Jul 20, 2017 at 4:31 PM, Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu>> wrote:
> 
>     On 7/20/2017 12:39 PM, Andreas Plesch wrote:
> 
> 
>         On Thu, Jul 20, 2017 at 3:13 PM, John Carlson <yottzumm at gmail.com <mailto:yottzumm at gmail.com> <mailto:yottzumm at gmail.com <mailto:yottzumm at gmail.com>>> wrote:
> 
>              There is a node tree in X3DJSAIL.   There’s two parts to X3DJSAIL, jsail (the implementation) and sai (the interface)
> 
> 
>     correct, as are your other points.
> 
>     There is some usage of DOM internally to the library, particularly when using Java reflection, but none of that is exposed to the programmer.
> 
>     Conceivably we could add some form of DOM import and export for X3DJSAIL object trees.
> 
>              Conversions
>     http://www.web3d.org/x3d/stylesheets/java/X3DJSAIL.html#Conversions <http://www.web3d.org/x3d/stylesheets/java/X3DJSAIL.html#Conversions>
> 
>         Ok. I think sai (lowercase), the interface, defined in X3DJSAIL, is quite different from the SAI defined in the standard (abstract, java or javascript), right ?
> 
> 
>     Actually no...  I have implemented the X3D Java SAI interfaces quite strictly, and then added the jsail concrete classes using them.
> 
> 
> Ok. I was getting the impression that it had to be different due to the DEF/USE, Routes, statement discussions.

Most of those kinds of things are not addressed in legacy Java SAI (which was oriented to support Script node).  X3DJSAIL added numerous methods to support them.

> SAI has importDocument
> 
> http://www.web3d.org/documents/specifications/19777-2/V3.3/Part2/functions.html#importDocument
> 
> where document is a DOM node org.w3c.dom.Node. For cobweb-dom, this is the main function to get the initial scene from the DOM into the x3d browser. Into where would X3DJSAIL import the DOM ? What is the equivalent to the 'Browser' ?

Sorry, not yet implemented as such in X3DJSAIL.  Though X3dLoaderObject does use DOM to load an .x3d file, and includes a utility method that provides a copy of the resulting DOM.  So it shouldn't be too hard to add that.

http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/X3DLoaderObject.html#getDomDocument--

I'd expect it would be implemented similarly to other import features, and assume tree of X3D node/field values were encoded in DOM.

>     Nevertheless have found a number of omissions and contradictions in the Java SAI language binding for X3D.  Issues list maintained on X3DJSAIL page at:
> 
>     ============================================================================
>     Specification Changes under Consideration
>     http://www.web3d.org/x3d/stylesheets/java/X3DJSAIL.html#SpecificationChanges <http://www.web3d.org/x3d/stylesheets/java/X3DJSAIL.html#SpecificationChanges>
> 
>     *  X3dJavaSpecificationChangesAndIssues.txt lists noted problems with the governing specification X3D Java SAI Language Bindings (ISO/IEC 19777-2).
>     http://www.web3d.org/x3d/stylesheets/java/X3dJavaSpecificationChangesAndIssues.txt <http://www.web3d.org/x3d/stylesheets/java/X3dJavaSpecificationChangesAndIssues.txt>
> 
> 
> Looking at these discoveries. I assume the referenced v3.0 spec. is substantially identical to v3.3 ?

Yes, primarily just a smaller tagset for 3.0 compared to 3.3.  (There were some changes to Viewpoint/GeoViewpoint around v3.1),

>     *  Specification prose is needed to define necessary support for DEF, USE and class attributes. 
> 
>     *  Consider appropriate specification issues for abstract SAI and corresponding encoding specifications.
>     *  Not needed: adding Annex D Java SAI Concrete Classes for standalone scene programming, since other approaches can be accomplished compatibly.
>     *  Mantis issue tracker keeps track of details, alternatives and resolution for each specification issue.
>     *  Web3D Consortium github (member-only access) is used to maintain editors-draft Web3D specifications in version control.
>     ============================================================================
> 
>         My mental model currently is: Use X3DJSAIL to conveniently compose and manage an (X3D looking) object graph (a 'scene'). The object graph can be serialized (written out) to XML (strings). The XML is processed by the X3D browser to an internal scene graph with state. Use SAI to directly manipulate the internal scene graph. Does that sound right ?
> 
> 
>     Yes.

... noting that multiple output string or file types can be created, as alternatives to XML.

also note that the program using X3DJSAIL has no rendering or interaction by itself; it is simply being used to create a valid scene graph that includes any/all information found in OM4X3D and the various file encodings.

of course, at that point, a program can do anything it wants.  so it is easy to consider how much easier it might be to create a new Java-based application (such as an X3D player) when all of the X3D input/output, data structures and validation is taken care of already.

> Ah, good, I am on the right track. There could be a shortcut in the sequence above if the x3d browser would be able to directly process the object graph into the internal scene graph. Let's assume xj3d could do that. I think that would include replacing USE nodes with references to their DEF nodes ? So the scene graph would not actually have a need for a USE property. Another step would be compiling Routes into a fromNodeField-toNodeField map. So the scene graph would not have a need to keep Route definitions at certain tree path locations. This is why I thought there is a difference between X3DJSAIL dealing with an object graph and SAI dealing with the actual X3D scene graph and state.

Since there is no rendering provided, live run-time performance and event passing is not provided.

That said, a new application can do whatever it wants (including the kinds of activities you list here) once it has built the scene graph.

Thanks for good questions.  Have just finished porting to a Windows 10 machine and am uploading a new release with small touchups and updates.

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