[x3d-public] X3D Object Model development, Java SAI implementation efforts, and consistency with HTML5
Don Brutzman
brutzman at nps.edu
Sun Aug 28 23:16:08 PDT 2016
Summary: lots of constructive progress on subject topics.
====================
1. Updates and resource links. Roy, is your latest X3D Object Model stylesheet up to date in version control? I may need to make an occasional change but do not want to create conflicts with your version. On our next telcon, let's continue to coordinate the corresponding X3D XML Schema updates and product deployment paths.
The deployed version of X3D Object Model is usually in pretty close synch, but the Java SAI will track development efforts.
Latest links are maintained at
X3D Specifications: XML Schema and DOCTYPE Validation
http://www.web3d.org/specifications
including
X3D Object Model (autogenerated from X3D XML Schema)
http://www.web3d.org/specifications/X3DObjectModel-3.3.xml
Draft open-source Java Scene Access Interface (JSAI)
http://www.web3d.org/x3d/stylesheets/java/javadoc
http://www.web3d.org/x3d/stylesheets/java/jars/X3dJavaSceneAccessInterface3.3.classes.jar
http://www.web3d.org/x3d/stylesheets/java/jars/X3dJavaSceneAccessInterface3.3.full.jar
Source tree
http://www.web3d.org/x3d/stylesheets/java/source/org/web3d/x3d/sai/
====================
2. String constants. I was able to create enumeration string constants in the source code. Here are representative patterns:
http://www.web3d.org/x3d/stylesheets/java/javadoc/org/web3d/x3d/sai/Text/FontStyle.html
http://www.web3d.org/x3d/stylesheets/java/source/org/web3d/x3d/sai/Text/FontStyle.java
Source excerpts:
/** Allowed enumeration value for family field */
public final String FAMILY_SANS = "SANS";
/** Allowed enumeration value for family field */
public final String FAMILY_SERIF = "SERIF";
/** Allowed enumeration value for family field */
public final String FAMILY_TYPEWRITER = "TYPEWRITER";
/** Allowed enumeration value for justify field */
public final String JUSTIFY_BEGIN = "\"BEGIN\"";
/** Allowed enumeration value for justify field */
public final String JUSTIFY_BEGIN_BEGIN = "\"BEGIN\" \"BEGIN\"";
/** Allowed enumeration value for justify field */
public final String JUSTIFY_BEGIN_END = "\"BEGIN\" \"END\"";
etc.
This helps authors set values without fear of string mangling, providing an important capability for quality code and checking correctness at compile time (rather than run time).
====================
3. Indicating simpleType. The X3D Object Model pattern of always listing definitions for every enumeration string within each X3D node definition is good. It allows us to generate all of these individually and programmatically reference them, e.g. FontStyle.JUSTIFY_BEGIN_END etc.
These simple useful additions should probably be added features in next Java Language Binding specification upgrade, and possibly the abstract SAI as well.
However, it hides the fact that these enumerations come from some other SimpleType definitions in the X3D Object Model. That might be useful information for a programmer.
Wondering:
a. should we include separate X3D XML Schema / X3D Object Model definitions like accessTypeNames, profileNames, justifyValues etc. as separate utility definitions in the codebase? (and if so, where in the API)
b. if so, we need to add that simpleType name somewhere local whenever it is repeated in a
<ConcreteNode>/<InterfaceDefinition>/<field>/<enumeration>
Possibly this might be entered as *type='profileName'* in the excerpt below:
<Statement name="X3D">
<InterfaceDefinition specificationUrl="http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#Header"
appinfo="X3D is the top-most XML element for an Extensible 3D (X3D) Graphics file.">
<componentInfo name="Core" level="1"/>
<field type="SFString" name="profile" use="required" *type='profileName'*>
<enumeration value="Core"/>
<enumeration value="Interchange"/>
<enumeration value="CADInterchange"/>
<enumeration value="Interactive"/>
<enumeration value="Immersive"/>
<enumeration value="MedicalInterchange"/>
<enumeration value="MPEG4Interactive"/>
<enumeration value="Full"/>
</field>
Seems like a good idea to add it - perhaps redundant in a literal sense, but it will always be correct and it remains consistent with the X3D Object Model pattern of being deliberately redundant to avoid abstraction/obscureness in order to facilitate correct usage and autogeneration.
====================
4. HTML5 <object> is consistent with HTML4. Note that the preceding FontStyle is an interface, intended to allow authors to compile their Java code and work with any browsers use of Script node (inside an X3D scene) or as a script containing Java within an object element in the external HTML page.
Of note is that the <object> element still works in HTML5. Excerpt from the W3C HTML5 Recommendation:
==============================================================================
https://www.w3.org/TR/html5/single-page.html#the-object-element
4.7.4 The object element
[... much prose skipping ...]
> All object elements have a legacy caller operation. If the object element has an instantiated plugin that supports a scriptable interface that defines a legacy caller operation, then that must be the behavior of the object's legacy caller operation. Otherwise, the object's legacy caller operation must be to throw a NotSupportedError exception.
>
> In the following example, a Java applet is embedded in a page using the object element. (Generally speaking, it is better to avoid using applets like these and instead use native JavaScript and HTML to provide the functionality, since that way the application will work on all Web browsers without requiring a third-party plugin. Many devices, especially embedded devices, do not support third-party technologies like Java.)
>
> <figure>
> <object type="application/x-java-applet">
> <param name="code" value="MyJavaClass">
> <p>You do not have Java available, or it is disabled.</p>
> </object>
> <figcaption>My Java Clock</figcaption>
> </figure>
>
> In this example, an HTML page is embedded in another using the object element.
>
> <figure>
> <object data="clock.html"></object>
> <figcaption>My HTML Clock</figcaption>
> </figure>
==============================================================================
This means that the Java SAI specification's approach of consistently working both
(a) internal to the X3D Scene within a Script node, and
(b) external to the X3D scene within an HTML5 <script> communicating to the X3D scene,
remains viable in HTML5.
So we should continue to try to support the existing X3D SAI, plus SAI Language Binding for Java, as completely as possible for both X3D v3.3 and X3D v4. *No disconnects or blockers have yet been found that might break forwards (or backwards) compatibility for X3D SAI and HTML5.*
Seems like pretty good news that supports execution of our X3D v4 strategies.
Of course there is always a Small Matter of Programming (SMOP) involved! 8)
https://en.wikipedia.org/wiki/Small_matter_of_programming
====================
5. Testing SAI interfaces.
This has begun using the specification examples found in
X3D Example Archives: Basic, Script Conformance
http://www.web3d.org/x3d/content/examples/Basic/ScriptConformance
The online archive only gets updated occasionally, source code is under subversion control at
http://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/content/examples/Basic/ScriptConformance
and the Ant-based build.xml file shows invocation progress.
====================
6. Am now working on concrete objects. Good progress generating and compiling code. This weekend's work is all checked in.
Found an apparent anomaly in X3D Object Model that prevents proper code generation:
<AbstractNodeType name="X3DRigidJointNode">
has
<AdditionalInheritance baseType="X3DBoundedObject"/>
but does not have corresponding definitions for
<field type="SFVec3f" accessType="initializeOnly" name="bboxCenter" default="0 0 0"/>
<field type="SFVec3f" accessType="initializeOnly" name="bboxSize" default="-1 -1 -1"/>
Hmmm, any ideas why those might have gone missing?
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
More information about the x3d-public
mailing list