CONSENSUS (preliminary, not cast in stone)

1. no overloading of prototypes (but maybe of eventhandlers!)
2. single inheritance, CLASS keyword, (so we can mix VRML 2.0 and our extensions), no EXTENDS keyword, inheritance implicit from first node
3. interfaces, INTERFACE keyword, EXTENDS keyword, multiple inheritance for interfaces
4. type system based on classes, helps to prevent run-time errors and to make restrictions more explicit
5. MF and SF are parts of the syntax, so if we have a class Transform we can use Transform, SFTransform and MFTransform as types in a specification.
6. no abstract classes (ABSTRACT keyword), use interfaces to this end

OPEN QUESTIONS

1. How does inheritance work, e.g.
   • superclass instances are added to the body of the PROTO (the VRML++ way)
   • superclass instances are added to the children field
   • the structural approach
2. Eventhandler and/or ROUTES
3. dynamic routing or an equivalent Eventhanlder concept
4. templates (as in C++), node types as parameters, e.g.

    PROTO p [ type X ] { X { } } 

5. macro mechanisms to define patterns like where to put arms and legs in a prototype, e.g. event names as parameters
6. EXTERNCLASS (problem how do you access default values or parts of the structure of the superclass, if the superclass is defined in another file)
7. overloading of events (or eventhandlers), e.g.

   PROTO Body [ eventIn SFNode addPart
   eventIn Arm addPart
   eventIn Leg addPart ]
   { #Eventhandler of addPart(SFNode n)
   #Eventhandler of addPart(Arm n)
   #Eventhandler of addPart(Leg n)
   }
   

   For each event, the most specific eventhandler is chosen. (This is useful for implementing visitor design patterns)
8. "private" and "public" keywords for fields and events: "private" properties are not inherited by subclasses.
9. A hierarchy for the standard nodes, e.g. the property of being a children node can be coded as an interface.
10. SELF and SUPER
    • SELF: in combination with dynamic routing, SELF can be used to create a ROUTE from the object itself to an event of a node received as a field value or by an event.
    • SUPER: An Eventhandler X can detect that it is not responsible to handle the received event and pass it on to its superclass: SUPER.X
      Or as part of the value of a field we can use the value of a field f of its superclass SUPER.f