[x3d-public] [x3d] AudioClip, MovieTexture interface hierarchy

[Don Brutzman]

cc: x3d-public

Deep-dive specification/schema review has been ongoing by the X3D Working Group in recent months.  Something just surfaced.

> On 6/7/2015 10:13 AM, Roy Walmsley wrote:
>> [...]
>>
>> Found the following:
>>
>> 1)The AudioClip <http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/sound.html#AudioClip> node
>> [... schema field issues ...]
>> On 6/7/2015 10:19 PM, Don Brutzman wrote:
>>> [... schema field fixes ...]
>>
>>> However a problem:  default containerField ought to be "source" but it is "children" due to eventual inheritance of X3DTimeDependentNode from X3DChildNode.

Current hierarchy:

     http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#f-Objecthierarchy

       X3DNode
         | [...]
         |
         +- X3DChildNode -+ [...]
                          |
                          +- X3DTimeDependentNode -+- TimeSensor (X3DSensorNode)*
                          |                        |
                          |                        +- X3DSoundSourceNode -+- AudioClip (X3DUrlObject)*
                          |                                               +- MovieTexture (X3DTexture2DNode, X3DUrlObject)*

* = Derived from multiple interfaces

also MovieTexture appears a second time, which is a warning that multiple inheritance is going on:

         |
         +- X3DAppearanceChildNode -+ [...]
         |                          |
         |                          +- X3DTextureNode -+-  [...]
         |                          |                  |
         |                          |                  +- X3DTexture2DNode -+- ImageTexture (X3DUrlObject)*
         |                          |                  |                    +- MovieTexture (X3DSoundSourceNode, X3DUrlObject)*
         |                          |                  |                    +- PixelTexture

Multiple inheritance (shown occurring here for MovieTexture) is contrary to the approach used throughout the rest of the X3D object hierarchy: single inheritance of one abstract X3D*Node type, plus multiple interfaces.  This avoids the "diamond inheritance" restriction in a number of programming languages.

	https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem

Suggested solution follows.

> this seems incorrect.  perhaps
> - X3DTimeDependentNode ought to be X3DTimeDependentObject, and
> - TimeSensor implements X3DChildNode and X3DTimeDependentObject, and
> - X3DSoundSourceNode implements X3DNode and X3DTimeDependentObject

and X3DSoundSourceNode type would instead become X3DSoundSourceObject interface, avoiding multiple inheritance.

The modified hierarchy would then look something like:

========================================================
       X3DTimeDependentObject
         |
         +- X3DSoundSourceObject

       X3DNode
         +- [...]
         |
         +- AudioClip (X3DSoundSourceObject, X3DUrlObject)*
         |
         +- [...]
         +- X3DAppearanceChildNode -+ [...]
         |                          |
         |                          +- X3DTextureNode -+-  [...]
         |                          |                  |
         |                          |                  +- X3DTexture2DNode -+- ImageTexture (X3DUrlObject)*
         |                          |                  |                    +- MovieTexture (X3DSoundSourceObject, X3DUrlObject)*
         |                          |                  |                    +- PixelTexture
         +- [...]
         +- X3DChildNode -+- [...]
         |                |
         |                +- TimeSensor (X3DSensorNode, X3DTimeDependentObject)*
         |
========================================================

This also fixes the problem that specification behavior for AudioClip and MovieTexture never indicates that they can be simple X3DChildNode "children" that can appear in isolation.  Rather, the only allowed content models are
-  MovieTexture under Appearance as a "texture", or
- MovieTexture/AudioClip under Sound as a "source".

In turn that would allow the Schema to assign a legal default containerField value for AudioClip (meanwhile MovieTexture is already OK in that regard).

So, how does the revised interface hierarchy look?  Scrutiny welcome.

If we decide a change is warranted, then...

> seems like broad buy-in would be needed.  if agreed, perhaps significant enough to be a separate v3.4 change rather than a v3.3 modification.

I think that this proposed modification fixes a long-standing, unintended error in the specification hierarchy.

Not clear yet how much of a problem such an interface reshuffling might pose for X3D player implementations.  I suspect that their class hierarchies are irregular anyway since the diamond inheritance problem will typically prevent direct implementation as described in the specification.  Note that diamond inheritance is sometimes referred to as the "deadly diamond of death" according to the wikipedia article!

We don't have to wait for v3.4 to correct specification errors; we can wait for 3.4 if we are evolving the design.

Follow-through efforts will continue on the X3D working group list, but all insights are of course welcome as we work on this important issue.

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