[x3d-public] X3D minutes 20 MAR 2020: X3DChildNode implementing X3DBoundedObject

[Don Brutzman]

I think you are correct that nodes which have X3DBoundedObject also have X3DChildNode.

Tried to apply this change: X3DChildNode implementing X3DBoundedObject interface.  (The other way around doesn't work, abstract interfaces can't implement abstract types).

However this change is not really possible: many nodes implement X3DChildNode but do not have X3DBoundedObject interfaces (BooleanFilter, BooleanToggle, ClipPlane etc. etc.)  See summary diagram (subtree under X3DChildNode) at

* Figure 4.2 — Interface hierarchy
   https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#f-Objecthierarchy

Documented this possibility in following new issue, then closed it.

* Mantis 1289: X3DChildNode implementing X3DBoundedObject interface
   https://www.web3d.org/member-only/mantis/view.php?id=1289

In passing, also found that some specification interface descriptions incorrectly refer to themselves as abstract node types which is incorrect (e.g. 10.3.1 X3DBoundedObject). Ensure all X3D*Object abstract interface definitions use correct nomenclature.  Entered issue 1288.

* Mantis 1288: ensure abstract interfaces are not referred to as abstract node types
   https://www.web3d.org/member-only/mantis/view.php?id=1288

"Fixed specification prose for X3DBoundedObject, X3DFogObject, X3DPickableObject and X3DProgrammableShaderObject."

On 3/21/2020 5:13 PM, Don Brutzman wrote:
> Another issue, but we didn't have time to discuss today.  TODO further specification review and X3D unified object model checks.
> 
>> [7] [x3d-public] X3DBoundedObject always X3DChildNode ?
>> https://web3d.org/pipermail/x3d-public_web3d.org/2020-February/011787.html
>>
>> "Ignoring for second the exception, I think that means there is a opportunity for simplification of the hierarchy by requiring X3DBoundedObject to implement X3DChildNode."

Full message:
=============
Nodes which implement X3DBoundedObject also implement X3DChildNode,
except for one node:
https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#f-Objecthierarchy

Ignoring for second the exception, I think that means there is a opportunity for simplification of the hierarchy by requiring X3DBoundedObject to implement X3DChildNode.

The exception is X3DNBodyCollisionSpaceNode (X3DBoundedObject)* -+-
CollisionSpace .

It seems curious that CollisionSpace is special. Could CollisionSpace
become a X3DChildNode ? It seems carefully defined not to be able to
participate in a Grouping but why ?

Refs:

https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#f-Objecthierarchy
https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/rigid_physics.html#CollisionSpace
=============

>> Thanks Andreas!
>>
>> More there, certainly seems worth following up.  We agreed it was worth further consideration, might possibly also resolve issue 1275.
>>
>> [7.1] Mantis 1282: is X3DBoundedObject always X3DChildNode ?
>> https://www.web3d.org/member-only/mantis/view.php?id=1282

As before, thanks for this interesting change suggestion.

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