[x3d-public] X3D Object Model development, Java SAI implementation efforts

Don Brutzman brutzman at nps.edu
Fri Sep 9 19:34:22 PDT 2016

summary: logic tracing and debugging via email, a tricky issue yields.

updates checked in.  results:

troubleshooting log follows for anyone interested in XML XPATH XSLT programming.

On 9/8/2016 11:45 PM, Don Brutzman wrote:
> [...]
> p.s.Noted a gap in X3D Object Model production: X3DViewpoint seems to be overlooked, perhaps others as well.

Looked into this further, Roy.

X3D object model does include

	<AbstractNodeType name="X3DViewpointNode"> ...

which include all expected <field> declarations from XML schema definition

	<xs:complexType name="X3DViewpointNode" abstract="true"> ...

_except for_ schema definition of

	<xs:attribute name="description" type="SFString"> ...

Not sure why this is getting excluded.

Looking at stylesheet BuildObjectModelXmlFile.xslt stylesheet, it appears that the relevant construct is within the block starting on line 195

	<xsl:element name="AbstractNodeTypes">

as part of the multi-line xpath selection, starting on line 252,

	<xsl:variable name="nonNodeFieldList" select="
   | //xs:schema/xs:complexType[@name=$greatGrandParentNodeType]/xs:annotation/xs:appinfo/xs:attribute
   | //xs:schema/xs:complexType[@name=$greatGrandParentNodeType]/xs:complexContent/xs:extension/xs:attribute
   | //xs:schema/xs:complexType[@name=$grandParentNodeType]/xs:attribute
   | //xs:schema/xs:complexType[@name=$grandParentNodeType]/xs:annotation/xs:appinfo/xs:attribute
   | //xs:schema/xs:complexType[@name=$grandParentNodeType]/xs:complexContent/xs:extension/xs:attribute
   | //xs:schema/xs:complexType[@name=$parentNodeType]/xs:attribute
   | //xs:schema/xs:complexType[@name=$parentNodeType]/xs:annotation/xs:appinfo/xs:attribute
   | //xs:schema/xs:complexType[@name=$parentNodeType]/xs:complexContent/xs:extension/xs:attribute
   | //xs:schema/xs:complexType[@name=$baseType]/xs:attribute
   | //xs:schema/xs:complexType[@name=$baseType]/xs:annotation/xs:appinfo/xs:attribute
   | //xs:schema/xs:complexType[@name=$baseType]/xs:complexContent/xs:extension/xs:attribute
   | xs:complexContent/xs:extension/xs:attribute
   | xs:annotation/xs:appinfo/xs:attribute
   | xs:complexType/xs:attribute
   | xs:attribute"/>

Despite the description attribute not being grabbed from the schema, sibling definitions for jump orientation andretainUserOffsets are captured OK.

Presumable the OK attributes are getting caught by line 265 above

    | xs:complexContent/xs:extension/xs:attribute

I used the following diagnostic to confirm that it was getting caught:

   <xsl:for-each select="$allFieldList">
	<xsl:sort select="lower-case(@name)"/>
         <!-- debug diagnostic -->
	<xsl:if test="($abstractNodeName='X3DViewpointNode') and (@name='description')">
			<xsl:text>*** Found X3DViewpointNode description in XML schema...</xsl:text>
	<xsl:call-template name="doField">
		<xsl:with-param name="containerName" select="$abstractNodeName"/>

which confirmed it was found successfully.

Now moving deeper, into your "doField" template, a similar debug statement at the top of the template found that the attribute indeed arrived there OK, as expected.

	<!-- debug -->
	<xsl:if test="(ancestor::*[@name='X3DViewpointNode'] and (@name='description'))">
			<xsl:text>*** Found X3DViewpointNode description in doField template...</xsl:text>

Now pressing on to discover why it got lost.

You have the following xsl:if statement to filter duplicates:

   <xsl:if test="(parent::xs:appinfo) or (not(parent::xs:appinfo) and not(../../../..//xs:annotation/xs:appinfo/xs:attribute[@name = $fieldName]))">

Hmmm.  I think what is happening is that the ../../../../ is reaching too high, then finding another independent element somewhere else with a 'description' attribute, and thus mistakenly rejecting it.  Ouch.

btw have grown wary of ../../../.. kinds of constructs with XML schema, because the relative hierarchies sometimes have a different number of levels.  Instead am now trying to use ancestor:: to get to the appropriate upper level, seems to be a more reliable xpath construct for this kind of thing.

so, with a little trial and error, got to the following replacement for ../../../.. to carefully exclude both cases of interest.

	<xsl:if test="(parent::xs:appinfo) or (not(parent::xs:appinfo) and
                                            not(ancestor::xs:complexType//xs:annotation/xs:appinfo/xs:attribute[@name = $fieldName]) and
                                            not(    ancestor::xs:element//xs:annotation/xs:appinfo/xs:attribute[@name = $fieldName]))">

boom presto, that worked!  a few dozen previously overlooked fields have appeared in the X3D Object Model.

once again, am also really liking the fact that changes to object model are checked into version control.  A diff quickly reveals that only additions have occurred and no removals.

looked at them all closely.  As hoped for, the following appeared under X3DViewpointNode and corresponding *Viewpoint nodes:

	<field type="SFString" accessType="inputOutput" name="description">
	   <componentInfo name="Navigation" level="2"/>

Rebuilding the Java SAI from object model XML is again a strong test:  some further rough edges were detected and corrected.

i left the XSLT debug diagnostic blocks in place, commented out, for potential future use.

all checked in and uploaded.  another step forward.  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 http://faculty.nps.edu/brutzman

More information about the x3d-public mailing list