[x3d-public] Object model definitions of DEF, USE, and class

Roy Walmsley roy.walmsley at ntlworld.com
Wed Jul 19 07:24:51 PDT 2017


Hi,

 

I have been considering the Object Model for X3D (OM4X3D). I noted the
following definition for the abstract node type X3DNode, which is inherited
by all nodes:

 

      <AbstractNodeType name="X3DNode">

         <InterfaceDefinition
specificationUrl="http://www.web3d.org/documents/specifications/19775-1/V3.3
/Part01/components/core.html#X3DNode"

                              appinfo="All instantiable nodes implement
X3DNode, which corresponds to SFNode in the X3D specification.">

            <componentInfo name="Core" level="1"/>

            <field type="SFNode"

                   accessType="inputOutput"

                   name="metadata"

                   default="NULL"

                   acceptableNodeTypes="X3DMetadataObject"/>

            <field type="SFString"

                   accessType="inputOutput"

                   name="DEF"

                   inheritedFrom="DEF_USE"/>

            <field type="SFString"

                   accessType="inputOutput"

                   name="USE"

                   inheritedFrom="DEF_USE"/>

            <field type="SFString"

                   accessType="inputOutput"

                   name="class"

                   inheritedFrom="globalAttributes"/>

            <ContentModel>

               <GroupContentModel name="ChildContentModelCore"
minOccurs="0"/>

            </ContentModel>

         </InterfaceDefinition>

      </AbstractNodeType>

 

The items in this listing that bother me are those for the "DEF", "USE" and
"class". These are common to all node types, both abstract and concrete.

 

Each of these is defined as a "field". Clearly, in X3D, these are not
"fields". They do not have the properties of "fields" in general, such as
"accessType", or of the SFString field type in particular.

 

I think these need to be defined in alternative terms, using terminology
that differentiates them from fields. I suggest "attribute". There may well
be better terms.

 

I propose that the definition above would be more accurately expressed as
follows:

 

      <AbstractNodeType name="X3DNode">

         <InterfaceDefinition
specificationUrl="http://www.web3d.org/documents/specifications/19775-1/V3.3
/Part01/components/core.html#X3DNode"

                              appinfo="All instantiable nodes implement
X3DNode, which corresponds to SFNode in the X3D specification.">

            <componentInfo name="Core" level="1"/>

            <field type="SFNode"

                   accessType="inputOutput"

                   name="metadata"

                   default="NULL"

                   acceptableNodeTypes="X3DMetadataObject"/>

            <attribute type="NMTOKEN"

                   name="DEF"

                   inheritedFrom="DEF_USE"/>

            <attribute type="NMTOKEN"

                   name="USE"

                   inheritedFrom="DEF_USE"/>

            <attribute type="NMTOKEN"

                   name="class"

                   inheritedFrom="globalAttributes"/>

            <ContentModel>

               <GroupContentModel name="ChildContentModelCore"
minOccurs="0"/>

            </ContentModel>

         </InterfaceDefinition>

      </AbstractNodeType>

 

I have suggested the "type" of each attribute might be "NMTOKEN". There may
well be better types. If not, then "NMTOKEN" would need some explanation.

 

One final observation, specific to the X3DNode abstract type, is the
"appinfo" text. This says the "X3DNode" "corresponds to SFNode in the X3D
specification". This is clearly not true. SFNode is a field type. X3DNode is
an abstract node type. The only relationship between the two is that any
node can be set as the "value" of an SFNode field type.

 

All the best,

 

Roy

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170719/20d66b24/attachment-0001.html>


More information about the x3d-public mailing list