to X3D Specifications: XML Schema and DOCTYPE Validation

X3D Regular Expressions (regexes)

to Web3D home page

Overview | Patterns | References | Tools | Contact

X3D Regular Expressions (regexes) are used to validate the correctness of string and numeric array values in an X3D scene.

Status. This document is a preliminary draft.

Overview to top

Regular expressions (regexes) define string grammars that efficiently and rigorously define allowable character patterns making up a data value.

Regexes themselves are carefully defined sequences of characters that form a search pattern, mainly used for string pattern matching. For example, this technique allows detection of well-formed (or incorrect) MFVec3f arrays of three-tuple floats in an X3D scene.

X3D regexes are utilized judiciously when the base types of XML Schema are insufficient to capture the necessary richness of X3D content validation. Like all aspects of X3D Schema validation, regex validation is reasonably high performance and optional.

Note that not all regex languages are completely consistent, thus small (but fundamentally important) variations can occur. This work strictly follows regex syntax for XML Schema.

X3D Regular Expressions are an important part of X3D Quality Assurance (QA) to maximize the correctness of X3D scene content.

Patterns for X3D Regular Expressions (regexes) to top

Existing data validation tools provide expressive power that is able to validate values to different degrees of fidelity.

  1. DOCTYPE (DTD). DOCTYPE validation can only check that attribute values are strings. In some cases, a strict set of allowed enumeration values is defined (such as legal names for profiles and components).
  2. XML Schema. Schema validation can check a large set of built-in data types. However, XML Schema validation is typically not able to fully check the correctness of array values. For example, an SFVec3f triplet (3-tuple) or an MFVec3f array can be checked to only contain floating-point values, but cannot be checked to have a multiple of three floats.
  3. Regular expressions (regexes). Regular expressions can define any regular grammar, and thus have arbitrary expressive power. Although definitions may be tricky to define, character patterns of arbitrary complexity are theoretically achievable.

The following regex patterns are candidates for use in X3D Schema and other validation tools.

SFVec3f and MFVec3f

References to top

The following references provide useful additional information about X3D, regular expressions and data validation.

  1. Davis, Mark. Unicode Regular Expression Guidelines, 1988.
  2. Friedl, Jeffrey E.F., Mastering Regular Expressions: Understand Your Data and Be More Productive 3rd Edition, O'Reilly and Associates, Sebastopol California, 2006.
  3. regular expression library
  4. Regular-expressions.Info website
  5. E-mail post: Regular expression checking for malformed floating-point numbers and excess leading zeros
  6. Wikipedia: Regular expression article.
  7. X3D field data types are defined in Annex 5. Field type reference X3D Abstract Specification.
  8. World Wide Web Consortium (W3C) Recommendation: XML Schema Definition Language (XSD) 1.1 Part 2 Datatypes with sections on Regular expressions, float checking, etc.
  9. X3D Specifications: XML Schema and DOCTYPE Validation include the latest versions of recommended XML Schemas and DOCTYPEs (DTDs) for X3D.
  10. X3D Resources provides links to numerous resources supporting X3D and VRML.
  11. X3D Scene Authoring Hints provide a collection of style guidelines, authoring tips and best practices to improve the quality, consistency and maintainability of X3D Graphics scenes.
  12. X3D Validator is a Web application that checks X3D scene validity.
  13. XML Schema Part 2: Datatypes Second Edition, World Wide Web Consortium (W3C) Recommendation. Includes sections on Type System, Built-in datatypes and Regular Expressions.

Tools to top

Links to tools of interest follow. Additional recommendations are welcome.

Contact to top

Questions, suggestions and comments about these resources are welcome. Please send them to Don Brutzman and Roy Walmsley (brutzman at, roy.walmsley at

Available online at

Version control of this document is maintained at

Updated: 12 October 2015