Extensible 3D (X3D) encodings
Part 5: JSON encoding
4 Concepts
4.1 Introduction and topicsThis clause describes key concepts in this part of ISO/IEC 19776. This includes the manner in which X3D constructs defined in ISO/IEC 19775-1 are encoded.
See Table 4.1 for the topics in this clause.
The following conventions are used throughout this part of ISO/IEC 19776:
Italics are used for event and field names, and are also used when new terms are introduced and equation variables are referenced.
A fixed-space font is used for URL addresses and source code
examples. ISO/IEC 19776 JSON encoding examples appear in bold,
fixed-space font.
Node type names are appropriately capitalized (e.g., “The Billboard node is a grouping node...”). However, the concept of the node is often referred to in lower case in order to refer to the semantics of the node, not the node itself (e.g., “To rotate the billboard...”).
With the exception of International Standards, throughout this part of ISO/IEC 19776, references to external documents are denoted using the “x.[ABCD]” notation, where "x" denotes in which clause or annex the reference is described and “[ABCD]” is an abbreviation of the reference title. References without the "x." are references to the bibliography. International Standards are referenced by their number and link to the appropriate entry in 2 Normative references.
EXAMPLE 2.[ABCD] refers to a reference described in Clause 2 and [EFGH] refers to a reference described in the Bibliography.
4.2 OverviewJSON (Javascript Object Notation) is a lightweight, text-based, data interchange format. It was derived from the ECMAScript programming language, but is programming language independent. JSON defines a small set of structuring rules for the portable representation of structured data. [JSON]
There is a fundamental correspondence between the elements of the abstract X3D scene graph and constructs in the JSON encoding. This section describes the design patterns that govern the correspondence.
An X3D file is structured as defined in 7.2.5 Abstract X3D structure of ISO/IEC 19775-1. This part of ISO/IEC 19776 specifies a syntax that satisfies the requirements specified by ISO/IEC 19775-1.
The JSON language, defined in ISO/IEC 16262, has no specific header. The JSON text of an X3D file shall have as its primary value a JSON Object.
4.3 JSON file syntaxThis clause describes the syntax of JSON-encoded, human-readable X3D files. The syntax of X3D in terms of the JSON encoding are presented in this part of ISO/IEC 19776. The semantics of X3D are as defined in ISO/IEC 19775-1. Rules for parsing and handling JSON-encoded documents are defined in ISO/IEC 16262.
A formal description of the JSON syntax for X3D may be found in Annex A JSON Schema.
Spaces, tabs, linefeeds, and carriage-returns, wherever they appear outside of JSON strings, are collectively termed whitespace. It's use is optional.
EXAMPLE: Whitespace may be used between JSON tokens to improve readability.
An X3D document server may strip whitespace from an X3D file before transmitting it.
Each node type defines the names and types of it's fields. These can be broadly classified into two main field types:
As defined in 4.3.2.10 Field property syntax a field statement consists of the encoded name of the field, a comma separator, and then the value or values. The field name shall always be a JSON string. To disambiguate language constructs that are not X3D nodes or structural statements a field name shall be prefixed as follows, with no change to the capitalization of the field name:
EXAMPLE: The Box node has three fields, namely metadata, size, and solid, as defined in the node signature in 13.3.1 Box of ISO/IEC 19775-1. When encoded into JSON these three field names are encoded as "-metadata", "@size", and "@solid" respectively.
The JSON language does not provide a native way to include comments. Comments may, however, be embedded within the X3D JSON encoding using the #comment syntax described in 4.4 Comments. META statement, as defined in 7.2.5.6 META statement, and/or Metadata, as defined in 7.2.4 Metadata of ISO/IEC 19775-1, should be used for persistent information such as copyrights or author information.
NOTE: Similar to field names a comment is prefixed with "#", so that the keyword becomes "#comment".
Field, event, PROTO, EXTERNPROTO, and node names shall not contain control characters (0x0-0x1f, 0x7f), space (0x20), double or single quotes (0x22: ", 0x27: '), sharp (0x23: #), parentheses (0x2a, 0x2b: ()), comma (0x2c: ,), period (0x2e: .), brackets (0x5b, 0x5d: []), backslash (0x5c: \) or braces (0x7b, 0x7d: {}). Further, their first character shall not be a digit (0x30-0x39), plus (0x2b: +), or minus (0x2d: -) character. Otherwise, names may contain any ISO 10646 character. X3D is case-sensitive.
EXAMPLE: “Sphere” is different from “sphere” and “BEGIN” is different from “begin.”
The following reserved keywords shall not be used for field, event, PROTO, EXTERNPROTO, or node names:
The JSON language does not define a specific header. An X3D encoded JSON file shall be a JSON object with a single property, which shall be an object with the name "X3D", as defined in 4.3.2.2 "X3D" property syntax. All other content shall be contained within the "X3D" object.
The "X3D" object shall contain the following configuration statement properties:
The "head" object, may optionally contain any combination of the following:
The "Scene" object, may contain any combination of the following:
Every JSON-encoded X3D file shall begin with the following four elements in the order listed:
{ "X3D": {
The JSON file may contain whitespace between any of the four elements.
The "X3D" object shall have the properties listed in Table 4.2. The first column lists the name of the property. The second column indicates whether the property is optional or required. The third column lists the reference to the detailed encoding of the property. The properties may appear in any order.
After the property definitions the "X3D" object shall be terminated with a right brace character '}'. This shall be followed by a second right brace character that terminates the JSON file. These two braces may be separated by whitespace.
Table 4.2 — "X3D" object properties
| Property | Required/Optional | Reference |
|---|---|---|
| "@profile" | Required | 4.3.2.3 "@profile" property syntax |
| "@version" | Required | 4.3.2.2.1 "@version" property syntax |
| "@xsd:noNamespaceSchemaLocation" | Optional | 4.3.2.2.2 "@xsd:noNamespaceSchemaLocation" property syntax |
| "-children" | Optional | 4.3.2.2.3 "-children" property syntax |
| "encoding" | Required | 4.3.2.2.4 "encoding" property syntax |
| "JSONSchema" | Optional | 4.3.2.2.5 "JSONSchema" property syntax |
| "head" | Optional | 4.3.2.4 "head" property syntax |
| "Scene" | Required | 4.3.2.8 "Scene" property syntax |
The "@version" property is required and is of type string, and shall have a legal value in accordance with 7.2.5.2 Header statement of ISO/IEC 19775-1. (For this version of this part of ISO/IEC 19776, the version number is "3.3".) This property is encoded as the name/value pair:
"@version": "3.3"
The "@xsd:noNamespaceSchemaLocation" property is optional and is of type string. This property is encoded as the name/value pair:
"@xsd:noNamespaceSchemaLocation": "<uri>"
The <uri> shall be a valid URI in accordance with 2.[RFC3986].
This property is a reference to the schema used in the XML encoding detailed in Part 1 of ISO/IEC 19776. This property is included in the JSON encoding to preserve the value during translations from XML to JSON and vice versa.
The "-children" property is optional and is an array type. Each item in the array shall be a comment, encoded in accordance with 4.4 Comments. An example encoding of the "-children" property is:
"-children": [
{
"#comment": "This is comment one"
},
{
"#comment": "This is comment two"
}
]
The JSON language does not explicitly define any character encoding information. JSON may be encoded as UTF-8, UTF-16 or UTF-32, with UTF-8 being the default encoding. Furthermore, JSON does not permit the inclusion of a byte order mark (BOM) in a JSON document (see 8.1 Character Encoding of RFC 7159).
The "encoding" property, which is required, and is of type string, specifies the character encoding of the file. The encoding value shall be one of "UTF-8", "UTF-16", or "UTF-32". An example of this name/value pair is:
"encoding": "UTF-8"
Editor's Note: JSON schemas are currently based on a draft reference not yet approved by IETF. Furthermore, the current draft RFC for JSON schema does not define how a JSON document refers to a corresponding JSON schema. This encoding specification may change to match any new referencing definition in an approved document.
The "JSONSchema" property is optional and is of type string. This property is encoded as the name/value pair:
"JSONSchema": "<uri>"
The <uri> shall be a valid Uniform Resource Identifier (URI) in accordance with 2.[RFC3986].
The URI for the schema used to validate conformance to this specification is http://www.web3d.org/specifications/x3d-3.3-JSONSchema.json. This schema is reproduced in Annex A JSON schema. Similar schemes may be used for other versions of X3D.
The "@profile" property is a required property of the "X3D" object. It is of type string and is encoded as the name/value pair:
"@profile": "<profileName>"
The <profileName> shall be the name of any of the profiles specified in ISO/IEC 19775-1.
The "head" property is an optional property of the "X3D" object. It is of type object, and shall have the properties listed in Table 4.3. The first column lists the name of the property. The second column indicates whether the property is optional or required. The third column lists the reference to the detailed encoding of the property.
Table 4.3 — "head" object properties
| Property | Required/Optional | Reference |
|---|---|---|
| "component" | Optional | 4.3.2.5 "component" property syntax |
| "unit" | Optional | 4.3.2.6 "unit" property syntax |
| "meta" | Optional | 4.3.2.7 "meta" property syntax |
| "-children" | Optional | 4.3.2.4.1 "-children" property syntax |
The "-children" property is optional and is an array type. Each item in the array shall be a comment, encoded in accordance with 4.4 Comments. An example encoding of the "-children" property is:
"-children": [
{
"#comment": "This is comment one"
},
{
"#comment": "This is comment two"
}
]
The "component" property is an optional property of the "head" object. It is an array type. Each item in the array shall be an object with two properties. Both properties are required.
The first property has the name "@name" and is of type string. It shall be the name of a component as specified in the various component clauses of ISO/IEC 19775-1.
The second property has the name "@level" and is of type integer. It shall be an integer identifying one of the available support levels specified in ISO/IEC 19775-1 for the component named in the "@name" property.
An example encoding of the "component" property is:
"component": [
{
"@name": "Navigation",
"@level": 3
},
{
"@name": "RigidBodyPhysics",
"@level": 1
}
]
The "unit" property is an optional property of the "head" object. It is an array type. Each item in the array shall be an object with three properties. All three properties are required.
The first property has the name "@category" and is of type string. It shall be the name of one of the four base unit categories specified in 4.3.6 of ISO/IEC 19775-1.
The second property has the name "@name" and is of type string. It is specified by the <name> field described in 7.2.5.5 of ISO/IEC 19775-1.
The third property has the name "@conversionFactor" and is of type number. It is specified by the <conversionFactor> field described in 7.2.5.5 of ISO/IEC 19775-1.
An example encoding of the "unit" property is:
"unit": [
{
"category": "length",
"name": "kilometre",
"conversionFactor": 1000
}
]
The "meta" property is an optional property of the "head" object. It is an array type. Each item in the array shall be an object with two properties. Both properties are required.
The first property has the name "@name" and is of type string that identifies the metadata. The second property has the name "@content" and is also of type string. It defines the value for the metadata identified by the "@name" property.
An example encoding of the "meta" property is:
"meta": [
{
"@name": "Description",
"@content": "This scene portrays a well-made bed suitable for Mother's Day"
}
]
The "Scene" property is a required property of the "X3D" object. It is of type object, and shall have the properties listed in Table 4.4. The first column lists the name of the property. The second column indicates whether the property is optional or required. The third column lists the reference to the detailed encoding of the property.
Table 4.4 — "Scene" object properties
| Property | Required/Optional | Reference |
|---|---|---|
| "-children" | Optional | 4.3.2.8.1 "-children" property syntax |
The "-children" property is optional and is an array type. Each item in the array shall be one of the following types of object:
Annex B Examples contains several examples that illustrate the encoding of the "-children" property.
A node is encoded as an object that is a property of the containing field. The name portion of the name/value object pair is the type of the node. All other content are properties of the object, as listed in Table 4.5. The first column of the table lists the name of the property. The second column lists whether the property is optional or required. The third column lists the reference to the detailed encoding of the property. A node object may contain any of the listed properties, in any order.
Table 4.5 — Node object properties
| Property | Required/Optional | Reference |
|---|---|---|
| "@DEF" | Optional | 4.3.2.9.1 "@DEF" property syntax |
| "@USE" | Optional | 4.3.2.9.2 "@USE" property syntax |
| "IS" | Optional | 4.3.2.13 "IS" property syntax |
| fields | Optional | 4.3.2.10 Field property syntax |
| "-children" | Optional | 4.3.2.9.3 "-children" property syntax |
The detailed encodings of each individual node are listed in 6 Encoding of nodes.
Annex B Examples contains several examples that illustrate the encoding of nodes.
The "@DEF" property is an optional property of a node object. It is of type string and is encoded as the name/value pair:
"@DEF": "<nodeName>"
The <nodeName> shall be any name in accordance with 4.4.3 DEF/USE semantics of ISO/IEC 19775-1.
The "@USE" property is an optional property of a node object. It is of type string and is encoded as the name/value pair:
"@USE": "<nodeName>"
The <nodeName> shall be the name of any previously used "@DEF" property.
The node type of the object containing this "@USE" property shall be the same as the node type containing the corresponding "@DEF" property.
NOTE: X3D semantics prohibits defining both "@DEF" and "@USE" on a single node. Further, each "@DEF" identifier must appear prior to any corresponding "@USE" reference.
If a particular node type as defined in ISO/IEC 19775-1 contains a children field in the node signature the encoding shall be as specified for that node and "-children" property.
If a particular node type as defined in ISO/IEC 19775-1 does not have a children field then a "-children" property may be added. This property shall be an array type. Each item in the array shall be either a ROUTE, encoded in accordance with 4.3.2.14 "ROUTE" property syntax, a comment, encoded in accordance with 4.4 Comments, an IMPORT statement, encoded in accordance with 4.3.2.16 "IMPORT" property syntax or an EXPORT statement, encoded in accordance with 4.3.2.15 "EXPORT" property syntax.
A field statement consists of the encoded name of the field, a comma separator, and finally the field's value(s). The following illustrates the syntax for a single-valued field:
"<fieldName>": <fieldValue>
The following illustrates the syntax for a multiple-valued (i.e. array) field, with the required comma separator between each value:
"<fieldName>": [<fieldValue1>, <fieldValue2>, <fieldValue3>]
Each node type defines the names and types of the fields that each node of that type contains. The same field name may be used by multiple node types. See 5 Field type reference of ISO/IEC 19775-1 for the specification of field types and 5 Encoding of fields in this specification for their detailed encodings.
A "ProtoDeclare" property is an optional child property of a "-children" property. It is of type object, and shall have the properties listed in Table 4.6. The first column lists the name of the property. The second column indicates whether the property is optional or required. The third column lists the reference to the detailed encoding of the property.
Table 4.6 — "ProtoDeclare" object properties
| Property | Required/Optional | Reference |
|---|---|---|
| "@name" | Required | 4.3.2.11.1 "@name" property syntax |
| "@appinfo" | Optional | 4.3.2.11.2 "@appinfo" property syntax |
| "@documentation" | Optional | 4.3.2.11.3 "@documentation" property syntax |
| "ProtoInterface" | Optional | 4.3.2.11.4 "ProtoInterface" property syntax |
| "ProtoBody" | Required | 4.3.2.11.5 "ProtoBody" property syntax |
| "-children" | Optional | 4.3.2.11.7 "-children" property syntax |
The "@name" property is a required property of the "ProtoDeclare", "ExternProtoDeclare", and "field" objects. It is of type string. This property is encoded as the name/value pair:
"@name": "<myName>"
The <myName> shall be any name encoded in accordance with 4.3.1 JSON encoding.
The "@appinfo" property, which is provided for metadata purposes only, is an optional property of the "ProtoDeclare", "ExternProtoDeclare", and "field" objects. It is of type string. This property is encoded as the name/value pair:
"@appinfo": "<data>"
The "<data>" shall be any valid JSON string.
NOTE: The "@appinfo" property typically contains a description of the "ProtoDeclare", "ExternProtoDeclare", or "field" objects.
The "@documentation" property, which is provided for metadata purposes only, is an optional property of the "ProtoDeclare", "ExternProtoDeclare", and "field" objects. It is of type string. This property is encoded as the name/value pair:
"@documentation": "<data>"
The "<data>" shall be any valid JSON string.
NOTE: The "@documentation" property typically contains a URL address for corresponding documentation describing the "ProtoDeclare", "ExternProtoDeclare", or "field" objects.
A "ProtoInterface" property is an optional property of the "ProtoDeclare" object. It is of type object, and shall have the properties listed in Table 4.7. The first column lists the name of the property. The second column indicates whether the property is optional or required. The third column lists the reference to the detailed encoding of the property.
Table 4.7 — "ProtoInterface" object properties
| Property | Required/Optional | Reference |
|---|---|---|
| "field" | Optional | 4.3.2.12.2 "field" property syntax |
| "-children" | Optional | 4.3.2.11.7 "-children" property syntax |
A "ProtoBody" property is a required property of the "ProtoDeclare" object. It is of type object, and shall have the properties listed in Table 4.8. The first column lists the name of the property. The second column indicates whether the property is optional or required. The third column lists the reference to the detailed encoding of the property.
Table 4.8 — "ProtoBody" object properties
| Property | Required/Optional | Reference |
|---|---|---|
| "-children" | Optional | 4.3.2.11.6 "-children" property syntax (ProtoBody only) |
The "-children" optional property of the "ProtoBody" object is an array type. Each item in the array shall be one of the following types of object:
The "-children" property, when contained in a prototype object other than "ProtoBody", is optional and is an array type. Each item in the array shall be a comment, encoded in accordance with 4.4 Comments. An example encoding of the "-children" property is:
"-children": [
{
"#comment": "This is comment one"
},
{
"#comment": "This is comment two"
}
]
An "ExternProtoDeclare" property is an optional child property of a "-children" property. It is of type object, and shall have the properties listed in Table 4.9. The first column lists the name of the property. The second column indicates whether the property is optional or required. The third column lists the reference to the detailed encoding of the property.
Table 4.9 — "ExternProtoDeclare" object properties
| Property | Required/Optional | Reference |
|---|---|---|
| "@name" | Required | 4.3.2.11.1 "@name" property syntax |
| "@url" | Required | 4.3.2.12.1 "@url" property syntax |
| "@appinfo" | Optional | 4.3.2.11.2 "@appinfo" property syntax |
| "@documentation" | Optional | 4.3.2.11.3 "@documentation" property syntax |
| "field" | Optional | 4.3.2.12.2 "field" property syntax |
| "-children" | Optional | 4.3.2.11.7 "-children" property syntax |
The "@url" property is required and is of type string. This property is encoded as the name/value pair:
"@url": "<uri>"
The <uri> shall be a valid URI in accordance with 2.[RFC3986]. It shall also meet the requirements of 4.4.5.3 EXTERNPROTO URL semantics defined in ISO/IEC 19775-1.
A "field" property is an optional property of a "ProtoInterface" or "ExternProtoDeclare" object. It is also an optional property of script and shader nodes. It is of type object, and shall have the properties listed in Table 4.10. The first column lists the name of the property. The second column indicates whether the property is optional or required. The third column lists the reference to the detailed encoding of the property.
Table 4.10 — "field" object properties
| Property | Required/Optional | Reference |
|---|---|---|
| "@name" | Required | 4.3.2.11.1 "@name" property syntax |
| "@accessType" | Required | 4.3.2.12.3 "@accessType" property syntax |
| "@type" | Required | 4.3.2.12.4 "@type" property syntax |
| "@value" | Optional | 4.3.2.12.5 "@value" property syntax |
| "-children" | Optional | 4.3.2.12.6 "-children" property syntax |
| "@appinfo" | Optional | 4.3.2.11.2 "@appinfo" property syntax |
| "@documentation" | Optional | 4.3.2.11.3 "@documentation" property syntax |
The "@accessType" property is a required property of the "field" object. It is of type string, and is encoded as the name/value pair:
"@accessType": "<accessType>"
The <accessType> shall be one of the four access types defined in 4.4.2.2 Field semantics of ISO/IEC 19775-1. They shall be encoded as the strings "initializeOnly", "inputOnly", "outputOnly", and "inputOutput" respectively.
The "@type" property is a required property of the "field" object. It is of type string, and is encoded as the name/value pair:
"@type": "<fieldType>"
The <fieldType> shall be one of the field types defined in 5.3 Field types of ISO/IEC 19775-1.
The "@value" property is an optional property of the "field" object. It may only be included when both of the following conditions are true:
This property is encoded as the name/value pair:
"@value": <value>
The <value> is the default value for the field encoded in accordance with the field type as detailed in 5 Encoding of fields.
The "-children" property is an optional property of the "field" object. It may only be included when both of the following conditions are true:
This property is encoded as the name/value pair:
"-children": <value>
The <value> is the default value for the field encoded in accordance with the field type as detailed in 5 Encoding of fields.
The "IS" property is an optional property of any node. It may only be included when it's parent node is inside a prototype definition. The "IS" property is of type object, and shall have the properties listed in Table 4.11. The first column lists the name of the property. The second column indicates whether the property is optional or required. The third column lists the reference to the detailed encoding of the property.
Table 4.11 — "IS" object properties
| Property | Required/Optional | Reference |
|---|---|---|
| "connect" | Required | 4.3.2.13.1 "connect" property syntax |
| "-children" | Optional | 4.3.2.13.2 "-children" property syntax |
An example encoding of the "IS" property is:
"IS": {
"connect": [
{
"@protoField": "myProtoField1",
"@nodeField": "myNodeField1"
},
{
"@protoField": "myProtoField2",
"@nodeField": "myNodeField2"
}
],
"-children": [
{
"#comment": "These are examples"
}
]
}
The "connect" property is a required property of the "IS" object. It is an array type. Each item in the array shall be an object with two properties. Both properties are required.
The first property has the name "@protoField" and is of type string. It shall be the name of a field in the prototype definition that contains the parent node of the "IS" object.
The second property has the name "@nodeField" and is of type string. It shall the name of a field in the parent node of the "IS" object.
The "-children" property of the "IS" object is optional and is an array type. Each item in the array shall be a comment, encoded in accordance with 4.4 Comments. An example encoding of the "-children" property is:
"-children": [
{
"#comment": "This is comment one"
},
{
"#comment": "This is comment two"
}
]
The "ROUTE" property is an optional property of some "-children" property arrays. It is of type object, and shall have the properties listed in Table 4.12. The first column lists the name of the property. The second column indicates whether the property is optional or required. The third column lists the reference to the detailed encoding of the property.
Table 4.12 — "ROUTE" object properties
| Property | Required/Optional | Reference |
|---|---|---|
| "@fromField" | Required | 4.3.2.14.1 "@fromField" property syntax |
| "@fromNode" | Required | 4.3.2.14.2 "@fromNode" property syntax |
| "@toField" | Required | 4.3.2.14.3 "@toField" property syntax |
| "@toNode" | Required | 4.3.2.14.4 "@toNode" property syntax |
An example of the encoding of a "ROUTE" object is:
"ROUTE": {
"@fromNode": "myNode1",
"@fromField": "myField1",
"@toNode": "myNode2",
"@toField": "myField2"
}
NOTE: "@DEF" identifies must appear in an X3D JSON-encoded scene prior to corresponding "@fromNode" and "@toNode" references.
The "@fromField" property is a required property of the "ROUTE" object. It is of type string, and is encoded as the name/value pair:
"@fromField": "<myField>"
The <myField> is the name of the field that the ROUTE is connected from.
The "@fromNode" property is a required property of the "ROUTE" object. It is of type string, and is encoded as the name/value pair:
"@fromNode": "<myNode>"
The <myNode> is the name of the node, set with a "@DEF" property, that the ROUTE is connected from.
The "@toField" property is a required property of the "ROUTE" object. It is of type string, and is encoded as the name/value pair:
"@toField": "<myField>"
The <myField> is the name of the field that the ROUTE is connected to.
The "@toNode" property is a required property of the "ROUTE" object. It is of type string, and is encoded as the name/value pair:
"@toNode": "<myNode>"
The <myNode> is the name of the node, set with a "@DEF" property, that the ROUTE is connected to.
The "IMPORT" property is an optional property of the "Scene" object. It is an array type, where each item is an object having the properties listed in Table 4.13. The first column lists the name of the property. The second column indicates whether the property is optional or required. The third column lists the reference to the detailed encoding of the property.
Table 4.13 — "IMPORT" item properties
| Property | Required/Optional | Reference |
|---|---|---|
| "@AS" | Optional | 4.3.2.15.1 "@AS" property syntax |
| "@importedDEF" | Required | 4.3.2.15.2 "@importedDEF" property syntax |
| "@inlineDEF" | Required | 4.3.2.15.3 "@inlineDEF" property syntax |
An example of the encoding of an "IMPORT" object is:
"IMPORT": [
{
"@AS": "myNodeAlias",
"@importedDEF": "myImportNode",
"@inlineDEF": "myInline"
}
]
The "@AS" property is an optional property of the "IMPORT" and "EXPORT" objects. It is of type string, and is encoded as the name/value pair:
"@AS": "<myNodeAlias>"
The <myNodeAlias> is the alias to be used for the name of the node being imported or exported.
The "@importedDEF" property is a required property of the "IMPORT" object. It is of type string, and is encoded as the name/value pair:
"@importedDEF": "<myImportNode>"
The <myImportNode> is the name of the node being imported, set by a "@DEF" property.
The "@inlineDEF" property is a required property of the "IMPORT" object. It is of type string, and is encoded as the name/value pair:
"@inlineDEF": "<myInline>"
The <myInline> is the name, set by a "@DEF" property, of the Inline node containing the node being imported.
The "EXPORT" property is an optional property of the "Scene" object. It is an array type, where each item is an object having the properties listed in Table 4.14. The first column lists the name of the property. The second column indicates whether the property is optional or required. The third column lists the reference to the detailed encoding of the property.
Table 4.14 — "EXPORT" item properties
| Property | Required/Optional | Reference |
|---|---|---|
| "@AS" | Optional | 4.3.2.15.1 "@AS" property syntax |
| "@localDEF" | Required | 4.3.2.16.1 "@localDEF" property syntax |
An example of the encoding of an "EXPORT" object is:
"EXPORT": [
{
"@AS": "myNodeAlias",
"@localDEF": "myNode",
}
]
The "@localDEF" property is a required property of the "EXPORT" object. It is of type string, and is encoded as the name/value pair:
"@localDEF": "<myExportNode>"
The <myExportNode> is the name, set by a "@DEF" property, of the node to be exported.
4.4 CommentsComments shall always be encoded within the array of a "-children" property. Each comment shall be encoded into a JSON object that has a single name/value pair property having the name "#comment" and value type of string. The encoding of two comments is illustrated in the following example:
"-children": [
{
"#comment": "This is comment one"
},
... (other content),
{
"#comment": "This is comment two"
}
]
4.5 File extension and MIME typesThe file extension for JSON files is ".json". The MIME type (see 2.[RFC2077]) for JSON encoded X3D files shall be "model/x3d+json".