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

[Don Brutzman]

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

updates checked in.  results:
	http://www.web3d.org/specifications/java/javadoc
	
	http://www.web3d.org/specifications/X3DObjectModel-3.3.xml

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:attribute
   | //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:message>
			<xsl:text>*** Found X3DViewpointNode description in XML schema...</xsl:text>
		</xsl:message>
	</xsl:if>
	<xsl:call-template name="doField">
		<xsl:with-param name="containerName" select="$abstractNodeName"/>
	</xsl:call-template>
   </xsl:for-each>

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:message>
			<xsl:text>*** Found X3DViewpointNode description in doField template...</xsl:text>
		</xsl:message>
	</xsl:if>

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"/>
	</field>

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