[X3D-Public] X3D Compressed Binary Encoding, requirements review

[Don Brutzman]

As discussed on today's call, the past requirements look pretty good...

Please holler now if you have any corrections or additions, we are now 
proceeding to prepare the Call for Contributions document.


On 3/29/2013 9:31 AM, Don Brutzman wrote:
> Steady work has continued our discussion and refinement of X3D
> Compressed Binary plans for 2013.
>
> Leonard and I have updated the wiki page to document progress and
> discussions in recent weekly meetings.
>
>      http://web3d.org/wiki/index.php/X3D_Binary_Compression_Capabilities_and_Plans
>
> We now seek feedback on the suitability of our original Requirements for
> X3D Compressed Binary Encoding that were successfully used a decade ago.
>   They still look pretty darn good.  Further additions and improvements
> and suggestions are welcome.
>
> ========================================================
>
> http://web3d.org/x3d/binary/X3dBinaryRFP.html#Requirements
>
> "The X3D Task Group has established the following overall requirements
> for binary encoding:"
>
> * X3D Compatibility. The compressed binary encoding shall be able to
> encode all of the abstract functionality described in X3D Abstract
> Specification.
> * Interoperability. The compressed binary encoding shall contain
> identical information to the other X3D encodings (XML and Classic VRML).
> It shall support an identical round-trip conversion between the X3D
> encodings.
> * Multiple, separable data types. The compressed binary encoding shall
> support multiple, separable media data types, including all node
> (element) and field (attribute) types in X3D. In particular, it shall
> include geometric compression for the following.
>          Geometry - polygons and surfaces, including NURBS
>          Interpolation data - spline and animation data, including
> particularly long sequences such as motion capture (also see Streaming
> requirement)
>          Textures - PixelTexture, other texture and multitexture formats
> (also see Bundling requirement)
>          Array Datatypes - arrays of generic and geometric data types
>          Tokens - tags, element and attribute descriptors, or field and
> node textual headers
> * Processing Performance. The compressed binary encoding shall be easy
> and efficient to process in a runtime environment. Outputs must include
> directly typed scene-graph data structures, not just strings which might
> then need another parsing pass. End-to-end processing performance for
> construction of a scene-graph as in-memory typed data structures (i.e.
> decompression and deserialization) shall be superior to that offered by
> gzip and string parsing.
> * Ease of Implementation. Binary compression algorithms shall be easy to
> implement, as demonstrated by the ongoing Web3D requirement for multiple
> implementations. Two (or more) implementations are needed for eventual
> advancement, including at least one open-source implementation.
> * Streaming. Compressed binary encoding will operate in a variety of
> network-streaming environments, including http and sockets, at various
> (high and low) bandwidths. Local file retrieval of such files shall
> remain feasible and practical.
> * Authorability. Compressed binary encoding shall consist of
> implementable compression and decompression algorithms that may be used
> during scene-authoring preparation, network delivery and run-time viewing.
> * Compression. Compressed binary encoding algorithms will together
> enable effective compression of diverse datatypes. At a minimum, such
> algorithms shall support lossless compression. Lossy compression
> alternatives may also be supported. When compression results are claimed
> by proposal submitters, both lossless and lossy characteristics must be
> described and quantified.
> * Security. Compressed binary encoding will optionally enable security,
> content protection, privacy preferences and metadata such as encryption,
> conditional access, and watermarking. Default solutions are those
> defined by the W3C Recommendations for XML Encryption and XML Signature.
> * Bundling. Mechanisms for bundling multiple files (e.g. X3D scene,
> Inlined subscenes, image files, audio file, etc.) into a single archive
> file will be considered.
> * Intellectual Property Rights (IPR). All technology submissions must
> follow the predeclaration requirements of the Web3D Consortium IPR
> policy in order to be considered for inclusion.
> ========================================================
>
> The X3D Compressed Binary Encoding will continue to be a regular topic
> at weekly meetings.  Our goal is issue the Call for Contributions in April.
>
> all the best, Don


all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman