7.1 Introduction

7.1.1 Name

The name of this component is "Core". This name shall be used when referring to this component in the COMPONENT statement (see 7.2.3.4 Component statement).

7.1.2 Overview

This clause describes the Core component of this part of ISO/IEC 19775. The Core component supplies the base functionality for the X3D run-time system, including the abstract base node type, field types, the event model, and routing. Table 7.1 lists the major topics in this clause.

7.2 Concepts

7.2.1 Overview of the core

The Core component provides the minimum functionality required by all X3D-compliant implementations. The Core component supplies the following abstract constructs:

1. X3D field types descended from the abstract type X3DField;
2. the base abstract node types X3DNode and X3DPrototypeInstance;
3. commonly used interfaces such as X3DBindableNode and X3DUrlObject;
4. utility types such as X3DRoute and X3DScene that are available only to application programmer interfaces for scripting and external scene access;
5. the X3D event model and routing;
6. abstract file structure; and
7. prototyping.

The Core component is a prerequisite component for all other X3D components.

The Core component may be supported at a variety of levels, allowing for a range of implementations that are conformant to the X3D architecture, object model and event model. For more information on these topics, see 4. Concepts.

7.2.2 Bindable children nodes

Several X3D nodes, such as Background, TextureBackground, Fog, NavigationInfo, and Viewpoint are bindable children nodes, inheriting from the abstract node type X3DBindableNode. These nodes have the unique behaviour that only one of each type can be bound (i.e., affect the user's experience) at any instant in time. The browser shall maintain an independent, separate stack for each type of bindable node. Each of these nodes includes a set_bind inputOnly field and an isBound outputOnly field. The set_bind inputOnly field is used to move a given node to and from its respective top of stack. A TRUE value sent to the set_bind inputOnly field moves the node to the top of the stack; sending a FALSE value removes it from the stack. The isBound event is output when a given node is:

1. moved to the top of the stack;
2. removed from the top of the stack;
3. pushed down from the top of the stack by another node being placed on top.

That is, isBound events are sent when a given node becomes, or ceases to be, the active node. The node at the top of the stack (the most recently bound node) is the active node for its type and is used by the browser to set the world state. If the stack is empty (i.e., either the X3D file has no bindable nodes for a given type or the stack has been popped until empty), the default field values for that node type are used to set world state. The results are undefined if a multiply instanced (DEF/USE) bindable node is bound.

The following rules describe the behaviour of the binding stack for a node of type <bindable node>, (Background, Fog, NavigationInfo, or Viewpoint):

4. During read, the first encountered <bindable node> is bound by pushing it to the top of the <bindable node> stack. Nodes contained within Inlines, within the strings passed to the Browser.createX3DFromString() method, or within X3D files passed to the Browser.createX3DFromURL() method (see 2.[I19775-2]) are not candidates for the first encountered <bindable node>. The first node within a prototype instance is a valid candidate for the first encountered <bindable node>. The first encountered <bindable node> sends an isBound TRUE event.
5. When a set_bind TRUE event is received by a <bindable node>,
   1. If it is not on the top of the stack: the current top of stack node sends an isBound FALSE event. The new node is moved to the top of the stack and becomes the currently bound <bindable node>. The new <bindable node> (top of stack) sends an isBound TRUE event.
   2. If the node is already at the top of the stack, this event has no effect.
6. When a set_bind FALSE event is received by a <bindable node> in the stack, it is removed from the stack. If it was on the top of the stack,
   1. it sends an isBound FALSE event;
   2. the next node in the stack becomes the currently bound <bindable node> (i.e., pop) and issues an isBound TRUE event.
7. If a set_bind FALSE event is received by a node not in the stack, the event is ignored and isBound events are not sent.
8. When a node replaces another node at the top of the stack, the isBound TRUE and FALSE eventOuts from the two nodes are sent simultaneously (i.e., with identical timestamps).
9. If a bound node is deleted, it behaves as if it received a set_bind FALSE event (see f above).

7.2.3 Sensors

Sensors are nodes that generate events based on external inputs to the scene graph, such as user input, changes to the viewing environment, messages from the network or ticks of the system clock. X3D defines the following types of
sensors:

1. Pointing device sensors (see 20, Point device sensor component),
2. Environmental sensors (see 22, Environmental sensor component),
3. Key device sensors (see 21, Key device sensor component),
4. Load sensors (see 9, Networking component), and
5. Time sensors (see 8, Time component).

Sensors are children nodes in the hierarchy and therefore may be parented by grouping nodes as described in 10.2.1, Grouping and children node types.

Each type of sensor defines when an event is generated. The state of the scene graph after several sensors have generated events shall be as if each event is processed separately, in order. If sensors generate events at the same time, the state of the scene graph will be undefined if the results depend on the ordering of the events.

It is possible to create dependencies between various types of sensors. For example, a TouchSensor may result in a change to a VisibilitySensor node's transformation, which in turn may cause the VisibilitySensor node's visibility status to change. For a detailed description of how dependencies among sensors are handled during execution, see 4.4.8.3 Execution model.

7.2.4 Abstract X3D structure

7.2.4.1 Organization

An X3D world is conceptually defined as a sequence of statements organized conceptually as a file. The first item in the file is the Header statement. The second item in the file is the PROFILE statement. The PROFILE statement may be optionally followed by one or more COMPONENT statements. The remainder of the file consists of the other elements defined in this Part of ISO/IEC 19775-1. Optional META statements shall follow any COMPONENT statements or, if there are no COMPONENT statements, the PROFILE statement. All other statements shall follow the statements described above.

Any additional X3D content loaded into the scene via Inline nodes or scenes loaded using createX3DFromStream, createX3DFromString, or createX3DFromUrl, shall be declared as having a profile that has an equal or smaller set of required functionality; i.e., there can be no components explicitly declared, or implied by the profile in that content, that requires functionality not declared in the original profile and component declarations for the containing scene.

Although an X3D world is described as being contained in a file, the file may be conceptual and created dynamically during run-time as described in 2.[I19775-2].

7.2.4.2 Header statement

The Header statement is an encoding-dependent statement containing the following elements:

1. identification of the standard being supported (for this standard, this is "X3D");
2. identification of the character encoding being supported (for this standard, this is "UTF-8", and
3. optional comments that may apply to the file.

While the exact representation of this information is dependent on the encoding, this information shall always be stored as human-readable text.

7.2.4.3 PROFILE statement

Every X3D application shall declare a profile at the beginning of execution. This declaration tells the browser the exact set of components and their support levels that are required for the application to run, allowing for a browser to dynamically load the appropriate components if it so desires, and providing a mechanism for strict conformance should the browser choose to enforce it. If a browser supports the combination of declared profile and components (see 7.2.4.3 COMPONENT statement), it may proceed with presenting the world; otherwise, it shall fail.

The profile is declared via a PROFILE statement immediately following the Header statement at the top of the file. The form of the PROFILE statement is:

PROFILE <name>

where name is a string that does not contain whitespace.

The following profiles are defined in this standard:

1. Interchange (see B, Core profile),
2. Interchange (see C, Interchange profile),
3. Interactive (see D, Interactive profile),
4. MPEG-4 interactive (see E, MPEG-4 interactive profile),
5. Immersive (see F, Immersive profile), and
6. Full (see G, Full profile).

7.2.4.4 COMPONENT statement

X3D applications may explicitly declare additional components required for the application to run. This is useful for combining features that do not appear together in a predefined profile, such as adding Humanoid Animation support to the Immersive profile. If a browser supports the combination of declared profile and components, it may proceed with presenting the world; otherwise, it shall fail.

Components are declared by COMPONENT statements at the top of the file, immediately following the PROFILE statement but preceding any other content. The form of the component statement is:

COMPONENT <name> <level>

where <name> is a string that does not contain whitespace, and <level> is a positive integer.

If support for a component at the desired level is implied by the application's declared profile, the declaration for that component is unnecessary but may be included.

7.2.4.5 META statement

X3D applications may explicitly declare metadata about the world being defined. This is done by adding one or more META statements that contain such information. Such statements do not affect the scene graph but simply provide additional information in the world.

Metadata is specified by META statements at the top of the file, immediately following the PROFILE and COMPONENT statements but preceding any other content. The form of the META statement is:

META <key> <data>

where <key> is a string that identifies the metadata and <data> is a string that defines the value for the metadata identified by <key>.

7.3 Abstract types

7.3.1 X3DBindableNode

X3DBindableNode : X3DChildNode {
  SFBool [in]  set_bind
  SFTime [out] bindTime
  SFBool [out] isBound
}

X3DBindableNode is the abstract base type for all bindable children nodes, including Background, TextureBackground, Fog, NavigationInfo and Viewpoint. For complete discussion of bindable behaviors, see 7.2.2, Bindable children nodes.

7.3.2 X3DNode

X3DNode {
}

This abstract node type is the base type for all nodes in the X3D system.

7.3.3 X3DPrototypeInstance

X3DPrototypeInstance : X3DNode {
}

This abstract node type is the base type for all prototype instances in the X3D system. Any user-defined nodes declared with PROTO or EXTERNPROTO are instantiated using this base type. An X3DPrototypeInstance may be place anywhere in the scene graph where it is legal to place the first node declared within the prototype instance. For example, if the base type of first node is X3DAppearanceNode, that prototype may be instantiated anywhere in the scene graph that allows for an appearance node (e.g. Shape).

7.3.4 X3DSensorNode

X3DSensorNode  : X3DChildNode {
  SFBool [in,out] enabled;
  SFBool [out]    isActive;
}

This abstract node type is the base type for all sensors.

7.4 Node reference

The Core component defines no concrete nodes.

7.5 Support levels

The Core component provides three levels of support as specified in Table 7.2. Level 1 is intended to enable strict compability for VRML 97 implementations with respect to event model, supported field types and routing semantics. Level 2 adds new features in X3D.

SFVec2d
MFVec2d
SFVec3d
MFVec3d