[X3D-Public] announce: X3D Tooltips now provide full support

Don Brutzman brutzman at nps.edu
Mon Oct 1 08:51:07 PDT 2012


I'm happy to report that the X3D Tooltips now provide full support for all nodes in X3D.

	X3D Tooltips
	http://www.web3d.org/x3d/content/X3dTooltips.html

The X3D tooltips provide summary descriptions and authoring hints for each X3D node (element) and field (attribute) in the version 3.3 specification. They provide context-sensitive support for authors and tools, with each node also providing appropriate links to the X3D Abstract Specification, the X3D Schema Documentation and the X3D DOCTYPE Documentation.

Recent work includes:
- addition of missing nodes from X3D version 3.2
- Separate Reference Version tooltips for X3D version 3.3, 3.2, 3.1 and 3.0 tooltips
- Additional languages include Chinese, French, German tooltips, Italian tooltips, Portuguese and Spanish tooltips. These are current as of X3D v3.1 (meaning the majority of nodes).
- Explanatory sections regarding accessType and type declarations, excerpts follow.

I hope that everyone finds these useful.  I frequently refer to them when authoring or teaching X3D.

If anyone is interested in updating any of the X3D Tooltips in other languages, please let me know. I can develop some diff scripts that will show differences with the complete Tooltips.

As ever, comments questions and improvements are welcome.  Have fun with X3D!

=====================================================
accessType Definitions

accessType determines whether a field corresponds to event input, event output, or persistent state information. Events are strictly typed values with a corresponding timestamp. ROUTE connections must match accessType between source field and target field.

    initializeOnly: can be initialized, but cannot send or receive events. This is usually the case for fields that are too computationally expensive to change at run time.
    initializeOnly: can be initialized, and can also send or receive events. This is usually the case for fields that are too computationally expensive to change at run time.
    inputOnly: cannot be initialized or included in a scene file, but can receive input event values via a ROUTE.
    outputOnly: cannot be initialized or included in a scene file, but can send output event values via a ROUTE.

X3D accessType design keeps 3D graphics rendering fast and interactive, also helping to keep X3D players small and lightweight.

=====================================================
type Definitions

Data types classify the possible values for a variable. X3D is a strongly typed language, meaning that data types must match for a scene to be correct. Each field in each node (i.e. each XML attribute) has a strictly defined data type. Multiple data types are provided for boolean, integer, floating-point and string values.

    Each of the base types are either single-value or multiple-value. Examples: SFFloat (single-value), SFVec2f (2-tuple), SFVec3f (3-tuple), SFOrientation (4-tuple for axis-angle values).
    Arrays are also provided for all base types. Nomenclature: SF = Single Field (single value of base type), MF = Multiple Field (array of base-types).
    The X3D Schema is able to validate numeric type information and array tuple sizes in X3D scenes for initializeOnly and inputOutput field initializations that appear within an X3D file.
    ROUTEs pass events, which are strictly typed values with a corresponding timestamp. ROUTE connections must match type between source field and target field. Since they are transient, event values themselves cannot appear within an X3D file.
    For MF multiple-field arrays, commas between values are normally treated as whitespace. However, X3D Schema validation will not accept commas that appear within vector values, only between values. MFColor examples: color="0.25 0.5 0.75, 1 1 0" is valid while color="0.25, 0.5, 0.75, 1, 1, 0" is invalid. This is an authoring assist to help authors troubleshoot errors in long arrays of values.
    Failure to match data types correctly is an error! Types must match during scene validation, scene loading, and at run time. This is A Good Thing since it allows authors to find problems when they exist, rather than simply hoping (perhaps mistakenly) that everything will work for end users.

Several Extensible Markup Language (XML) data types are also included in these tooltips.

    CDATA is an XML term for Character Data. The base type for all XML attributes consists of CDATA characters. CDATA is used throughout the X3D DOCTYPE definitions, which can only check for the presence of legal strings and thus are not able to validate numeric type information. Strictly speaking, a few CDATA attributes (such as those for the meta element and other elements appearing inside the head element) are not fields of X3D nodes and thus do not have corresponding X3D data types.
    FIXED indicates that no other value is allowed. When used with an empty string "" value, this is used to indicate that X3D inputOnly and outputOnly fields are not allowed to appear in an X3D file.
    ID is a NMTOKEN that is unique within the scene, corresponding to the DEF label in X3D.
    IDREF is a reference to one of these unique scene IDs, corresponding to the USE label in X3D.
    NMTOKEN is an XML term for Name Token. NMTOKEN is also a CDATA string but must also match naming requirements for legal characters with no embedded spaces.

The following table provides a complete list of X3D data type names, descriptions and example values.
[...]
=====================================================

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



More information about the X3D-Public mailing list