Extensible 3D (X3D) encodings
Part 3: Binary encoding

4 Concepts

--- X3D separator bar ---

cube 4.1 Introduction and topics

4.1.1 Introduction

This clause describes key concepts in this part of ISO/IEC 19776. This includes how the X3D constructs defined in ISO/IEC 19775-1 are encoded as a binary file.

4.1.2 Topics

Table 4.1 lists the topics is this clause.

Table 4.1 — Topics in this clause

4.1 Introduction and topics
  4.1.1 Introduction
  4.1.2 Topics

4.2 Overview
  4.2.1 Introduction
  4.2.2 The structure of an X3D file
  4.2.3 X3D Canonical Form
  4.2.4 Header
  4.2.5 Prototype representations

4.3 Compressed binary X3D file syntax
  4.3.1 Geometric compression
  4.3.2 Additional field compression
  4.3.3 XML signature and encryption
  4.3.4 XML binary compression using Fast-InfoSet

4.4 X3D files and the World Wide Web
  4.4.1 gzip compression
  4.4.2 File extension and MIME type

cube 4.2 Overview

4.2.1 Introduction

This X3D encoding provides a compact transmission format that minimizes delivery size and maximizes parsing speed. Privacy and ownership protections are optionally provided using XML Security mechanisms. Size, parsing and security capabilities are typically superior to that provided by simple gzip compression alone.

There is an essential one-to-one match between the nodes and fields of the abstract X3D scene graph and corresponding constructs in the binary encoding. This section describes the design patterns that govern the correspondence.

Part 1 of ISO/IEC 24824 specifies the technique used to encode a binary stream representing an X3D scene graph. This technique has the name of Fast-InfoSet. Conceptually, a slightly modified X3D XML-encoded document is fed to a Fast-InfoSet processor to write the binary stream. Implementations are not required to follow this conceptual model.

The following compression steps are provided for the X3D compressed binary encoding. The actual processing order and methods of accomplishment may vary between applications. An implementation may skip any step so long as the resultant binary file is the same as if these steps were followed.

4.2.2 The structure of an X3D file

An X3D file is structured as specified in ISO/IEC 19775-1.

4.2.3 X3D Canonical Form

Conceptually, the X3D scene input to the Fast-InfoSet encoder is an XML-encoded document with certain restrictions. X3D Canonical Form eliminates file ambiguities that have no impact on the 3D content but which otherwise would negatively impact security issues, compression or parsing performance.

The following X3D canonicalization restrictions are applied to an X3D scene (or scene fragment) prior to encryption, signature or compression:

  1. Whitespace rules:
  2. Quotation marks and apostrophes:
  3. Default or substitute Document Type Definition (DTD) as specified in Part 1 of ISO/IEC 19776 is included following the <?xml version="1.0" encoding="UTF-8"?> header in canonical form.

    NOTE  The default DTD is not included in the final binary encoding, only substitute DTD values are compressed.

  4. Default or substitute X3D Amendment 1 Schema attributes included in the root <X3D> element.

    NOTE  The default X3D Schema attributes are not included in the final binary encoding, only substitute X3D Schema attributes are compressed.

  5. Floating point and double precision.
  6. Attributes with empty values are eliminated. Attributes with default values are eliminated, in order to reduce encoded file size. Default values can be determined from the X3D DTD or X3D Schema. This rule supercedes the XML canonicalization rule that all attribute values are provided.
  7. Attribute-value pairs for DEF, USE and (non-default) containerField must appear before other attributes, which then follow in alphabetic order. This ordering typically provides higher parsing performance during subsequent decoding. This step supercedes the XML canonicalization rule that all attribute values are provided in alphabetic order.
  8. All MFNode content for a child field shall be provided in a contiguous block with no intermixed containerField usage.

    EXAMPLE the following code exhibits X3D not in this form:

          <Collision>
             <Shape containerField="children" />
             <Shape containerField="proxy" />
             <Shape containerField="children" />
          </Collision>

    The canonical form would be:

          <Collision>
             <Shape containerField="proxy" />
             <Shape containerField="children" />
             <Shape containerField="children" />
          </Collision>
  9. Comment sections may be included or omitted, as selected by the scene author. Since default values for X3D compressed binary encoding are lossless, comments are retained by default.
  10. SFImage data is written in hexadecimal form separated by normalized whitespace.
  11. CDATA sections (typically, Ecmacript or shader source code) do not need to be converted into character entities.
  12. Except where specifically overridden by the preceding rules, apply the rules of XML canonicalization, summarized here:
    1. comments may optionally be included
    2. normalize line feeds
    3. normalize attribute values
    4. resolve character and parsed entity references
    5. sort attributes lexicographically
  13. X3D scenes in canonical form shall be well-formed, validated XML. This property is an important prerequisite to subsequent XML-based compression techniques.

4.2.4 Header

The header follows the Fast-InfoSet rules for header declaration as defined in 12.3 of Part 1 of ISO/IEC 24824. A valid X3D Binary encoded file will contain either an XML file declaration (see 2.[XML]) followed by the Fast-InfoSet header bits '11100000000000000000000000000000000' or just the Fast-InfoSet header bits.

EXAMPLE  Example headers:

<?xml encoding='finf'?>'11100000000000000000000000000000000'

<?xml version='1.0' encoding='finf' standalone='yes'?>'11100000000000000000000000000000000'

Other XML header elements like the DTD or schema definition are encoded using standard Fast-InfoSet mechanisms.

Three additional fields are appended to the X3D tag to denote X3D binary version information. These attributes are:

  1. binaryVersion,
  2. serializerVersion, and
  3. geometricCompressionVersion.

EXAMPLE

<X3D    
binaryVersion="3.1"
serializerVersion="FastInfoSet 2004"
geometricCompressionVersion="Java3D 2004" 
>
   
</X3D>
SFString
SFString
SFString 
[initializeOnly]
[initializeOnly]
[initializeOnly]

4.2.5 Prototype representations

All Prototype-related elements are treated in a manner consistent with the representations of the X3D XML encoding. Thus, Prototype instances are treated as PrototypeInstance constructions in XML.

EXAMPLE

  <ProtoDeclare name="ExampleSensor">
   <ProtoInterface>
     <field accessType="initializeOnly" name="enabled" type="SFBool" value="true"/>
   </ProtoInterface>
   <ProtoBody>
     <TouchSensor description="touch to activate">
      <IS>
       <connect nodeField="enabled" protoField="enabled"/>
      </IS>
     </TouchSensor>
    </ProtoBody>
   </ProtoDeclare>
   <ProtoInstance name="ExampleSensor">
    <fieldValue name="enabled" value="false"/>
   </ProtoInstance>

The following "native-tag" representations is not legal and shall not be used within the compressed binary encoding:

   <ExampleSensor enabled="false"/>

4.3 Compressed Binary X3D file syntax

4.3.1 Node Compression

Specific compression techniques for individual nodes is described in 6 Encoding of Nodes

These techniques will override all field specific rules. The compressor is responsible for encoding all data needed to reconstitute the node. A node compressor must retain all scenegraph structure and DEF/USE relationships.

4.3.2 Additional field compression

Further type-specific field compression is specified in 5 Encoding of fields.

4.3.3 XML signature and encryption

Encryption of X3D files is handled using W3C Recommendation XML Encryption Syntax and Processing. The standard provides encryption capabilities at the document, node and field levels. The granularity of encryption used is up to the encoding application.

EXAMPLE 1  Encryption of an IndexedFaceSet:

<?xml version='1.0'?>
<X3D>
   <Scene>
      <Shape>
         <IndexedFaceSet>
            <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
               Type='http://www.w3.org/2001/04/xmlenc#Content'>
               <CipherData>
                  <CipherValue>A23B45C56</CipherValue>
               </CipherData>
            </EncryptedData>
         </IndexedFaceSet>
      </Shape>
   </Scene>
</X3D>

EXAMPLE 2  Encrpytion of a whole document:

  <?xml version='1.0'?>
  <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
   MimeType='text/xml'>
    <CipherData>
      <CipherValue>A23B45C56</CipherValue>
    </CipherData>
  </EncryptedData>

4.3.4 XML binary compression using Fast-InfoSet

This part of ISO/IEC 19776 uses Fast-InfoSet to serialize and compress an X3D document. It uses several techniques that reduce the size of an X3D document and that increase the speed of creating and processing such documents. These techniques are based on the use of vocabulary tables that allow small (typically) integer values (vocabulary table indexes) to be used instead of character strings (for example, character strings that form the names of nodes or fields in an X3D document).

A further important optimization uses the encoding algorithm vocabulary table. This table identifies specialized encodings that can be employed for commonly occurring strings, again with a number of built-in algorithms. For example, if there is a string which looks like the decimal representation of an integer in the range -32768 to 32767, that string can be encoded by identifying that this vocabulary table is being used, giving the vocabulary table index, and then encoding the integer as a two-octet signed integer. Floating-point numbers and arrays of such numbers are supported in the same way. This part of ISO/IEC 19776 defines several unique encoders for X3D that utilize type-aware knowledge to further compress data. Further details are specified in 5 Encoding of fields.

cube 4.4 X3D files and the World Wide Web

4.4.1 gzip compression

An optional final step is gzip compression of the entire compressed scene. This step supports global compression, while the other compression techniques described in this part of ISO/IEC 19776 tend to be localized to individual chunks of data.

NOTE  gzip compression of compressed binary encoded scenes may have a negative impact on parser processing performance during decompression.

4.4.2 File extensions and MIME types

Binary compressed X3D encoded files shall use the file extension “.x3db”. The MIME-type associated with that binary compressed X3D encoded file is “model/x3d+binary”.

Binary compressed X3D encoded files that have been “gzipped” shall use a file extension of “.x3db.gz”. The MIME type is “model/x3d+binary”. The content-encoding value is “gzip”.

The concept of MIME types is defined in 2.[MIME].

--- X3D separator bar ---