[x3d-public] Building an X3D Object Model - step 1

Roy Walmsley roy.walmsley at ntlworld.com
Thu Oct 19 06:07:46 PDT 2017


Hi,

 

Let's say, for the sake of discussion and greater understanding, that you
wanted to build an Object Model for X3D from scratch. Where would you start?

 

In the first instance let's confine our work to the requirements of the
abstract standard ISO/IEC 19775-1:2013. We'll add in the requirements from
the SAI in ISO/IEC 19775-2:2015 in later steps.

 

Let's start with the abstract standard ISO/IEC 19775-1:2013, clause 4.4.2.1
Overview, which is the first subclause in clause 4.4.2 Object model.

Reference:
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.h
tml#ObjectmodelOverview

 

The opening words read: "The X3D system is made up of abstract individual
entities called objects." What, in X3D, constitutes an object? The answer is
in paragraph two, which introduces two types of objects. These are "fields",
derived from  the X3DField object, and "nodes", derived from the X3DNode
object. Furthermore, nodes contain fields.

 

So, since nodes contain fields, let's start with fields. What
characteristics are common to all fields? Let's look at the fifth paragraph.
It states "Each object has the following common characteristics:", and lists
two characteristics, namely "A type name", and "An implementation". But,
wait a minute, the second sentence of the opening paragraph states "This
part of ISO/IEC 19775 defines a functional specification for each object
type but does not dictate implementation.".

 

Problem 1: The use of the term implementation is confusing. According to
that second sentence each object has "A functional specification". That
should be list item b.

 

Problem 2: There is a further problem with the use of the term
"implementation". The seventh paragraph states "Node implementations can
come from two sources, built-in nodes and prototypes.". "Implementations" is
the wrong word. What is really meant is "instantiations", which is a term
that is already defined at 3.1.39 in the standard.

 

Solely considering fields, what are the other characteristics common to all
fields? Clause 4.4.2.2 Field semantics has some. The first one it describes
is the type of access. The second one, which is not explicitly stated, but
assumed, is that it has a value (or values, depending on the type). The
third one, again not explicitly stated, is that it has a name.

Reference:
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.h
tml#FieldSemantics

 

So, from the perspective of an object model, we have identified four
characteristics that are common to all fields, namely:

1.	Type
2.	Access type
3.	Value(s)
4.	Name

 

However, the "value" characteristic varies with the field type, so we'll
leave that to each individual field type. So, our object model for the
X3DField class, from which all fields are defined is:

 

X3DField {

    type;

    accessType;

    name;

};

 

However, we also need to indicate the data type of each of these
characteristics, i.e. what data type is "type"? And so on. 

 

Starting with "accessType", we'll define an enumeration named AccessType,
that has the four values defined in 4.4.2.2, and we'll use the term "enum"
to represent an enumeration. The definition then becomes:

 

enum AccessType {

    initializeOnly,

    inputOnly,

    outputOnly,

    inputOutput

};

 

[

For reference, we'll also define a grammar for an enumeration within the
object model as follows:

enumeration -> enum <name> { enumerationValues } ; 

enumerationValues -> <enumValue> | <enumValue> , enumerationValues

]

 

Similar to "accessType" we can define an enumeration for "type", as follows,
taking the types from clause 5 Field type reference:

Reference:
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/fieldsDef.
html

 

enum Type {

    SFBool,

    MFBool,

    SFColor,

   .

};

 

Finally, lets define a primitive data type called "string", and use this as
the data type the name characteristic.

 

Our object model definition for the X3DField object now looks like:

 

X3DField {

    enum Type type;

    enum AccessType accessType;

    string name;

};

 

Now let's look at the object X3DArrayField, which is defined in clause 5.2.2
X3DArrayField

Reference:
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/fieldsDef.
html#X3DArrayField

 

We note that all fields that hold an array of values are derived from this
class. Furthermore, referring back to the second paragraph of clause
4.4.2.1, we see that "Objects . called fields . are derived from the
X3DField
<http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/fieldsDef
.html#X3DField>  object. So,  although not explicitly stated, we can
conclude that X3DArrayField must derive from X3DField. So does X3DArrayField
need any additional characteristics to those defined in X3DField. For now,
the answer is no. So the definition for X3DArrayField is as follows:

 

X3DArrayField : X3DField {

};

 

Step 2, to follow, will add the abstract functionality defined in ISO/IEC
19775-2:2015. Scene access interface (SAI).

 

All the best,

 

Roy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20171019/8a5a67a7/attachment-0001.html>


More information about the x3d-public mailing list