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

[John Carlson]

Are you going to define X3DNode in step 2?

On Oct 19, 2017 9:08 AM, "Roy Walmsley" <roy.walmsley at ntlworld.com> wrote:

> 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.html#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.html#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
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20171019/e4b81e74/attachment.html>