Difference between revisions of "X3D Compressed Binary Encoding Call For Contributions"

Revision as of 16:36, 5 April 2013

Summary

TODO: Make it clear that "Each individual contribution is expected to provide a specific technical capability that has the potential to work well within the existing framework" (from Requirements) allows small contributions that fit within the larger framework described below. It is important that we are not requiring a complete contributed solution. A complete solution may actually be undesirable in that it would "compete" with other contributions and the best features of the contributions could not be integrated together.

Background

Requirements

Each individual contribution is expected to provide a specific technical capability that has the potential to work well within the existing framework.

The overall requirements for the final standard are listed here.

• X3D Compatibility. The compressed binary encoding shall be able to encode all of the functionality described in X3D Abstract Specification.
  • This means that compressed functionality includes the full capabilities of X3D scenes.
• Interoperability. The compressed binary encoding shall contain identical information to the other X3D encodings (XML-based .x3d and ClassicVrml-based .x3dv).
  • This requirement includes 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
  • Web datatypes: wherever possible, datatype approaches are aligned to match Web standards.
• Processing Performance. The compressed binary encoding shall be easy and efficient to process in a run-time environment.
  • Compression 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.
  • Asymmetric options for higher-computation compression by authors or servers can result in smaller bandwidth and faster loading by end users.
• 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 as a Web3D/ISO standard, including at least one open-source implementation.
  • A test suite will be used for repeatable measurement and refinement of file-size and performance results.
• Streaming. Compressed binary encoding are utilized in a variety of network-streaming environments.
  • Scene retrieval can be performed via http/https, local file systems and standardized protocols, at various (high and low) bandwidths.
  • Network-capable level-of-detail support and progressive mesh refinement are important goal capabilities.
  • Javascript Object Notation (JSON) data transfer holds great potential value for Web-based streaming
• Authorability. Compressed binary encoding shall consist of implementable compression and decompression algorithms.
  • Common X3D authoring tools and players can easily support compression for scene-authoring preparation, network delivery and run-time viewing.
• Compression. Compressed binary encoding algorithms can together enable effective composition 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. Security considerations must be listed for all capabilities. If none are known for a given contribution, so state.
  • Compressed binary encoding will optionally enable security, content protection, privacy preferences and metadata such as encryption, conditional access, and watermarking.
  • Default solutions for most security requirements are already defined and demonstrated by the W3C Recommendations for XML Encryption and XML Signature.
  • Unencumbered Digital Rights Management (DRM) schemes that can work within this open Web standards framework are eligible for consideration.
• 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.
  • Similar bundling capabilities are emerging for uncompressed X3D scenes embedded within HTML pages.
• Intellectual Property Rights (IPR). IPR requirements must be met prior to consideration of any new technologies.
  • All technology submissions must follow the predeclaration requirements of the [Web3D Consortium IPR policy].
  • All technology results in the X3D standards are royalty free (RF). Patented contributions are welcome if royalty-free Web use is guaranteed.

Design Basis

RFP Process

Milestones