Schema for the Extensible 3D (X3D) tagset, updating the Virtual Reality Modeling Language (VRML). appinfo text. - Ensure setup and configuration files properly documented and available online as part of X3D-Edit distribution. - VRML 97's Script node Browser class (for values exposed to a browser) is being provided via attributes on Scene node (and thus a Scene interface). Also need to update DTD, X3D-Edit tooltips profile and X3dToVrml97.xsl translation stylesheet. - Use attributeGroup for any attributes contained in complexType (meaning NodeType definitions) so that multiple-interface repetitions can refer to the proper attributeGroup rather than explicitly repeating each attribute. - SceneGraphStructureType interface identifies scene-related nodes that are not renderable nodes in the scene graph (X3D, Header, Scene, ROUTE etc.). - Scene Authoring Interface (SAI) Java bindings for interfaces in org/web3d/x3d/sai/SceneAuthoringInterface.java are autogenerated from X3dSchemaDraft.xml by BuildInterfacesFromSchema.xsl - Enumeration types originally converted to Java interfaces, now converted into fully functional utility classes. - Can X3D element be formally designated as root node? Apparently not, according to revised Schema recommendation. Nevertheless, structured relationships of the node typing rules makes X3D the root. No further action required. - SceneGraphStructureNodeType nodes (X3D, Scene, Header, Prototype* etc.) changed from Full profile to either Base or Core profile as appropriate. - Updated to match final 2001 XML Schema Recommendation revisions. - Investigate restrictions on use of abstract="true" for element content as described in http://www.w3.org/2000/05/12-xmlschema-lcissues.html#abstract-types - Profile renaming: Core to Interchange profile CoreInteractive to Interactive profile BaseLine to Immersive profile Full stays Full profile, so far DisJavaVrml to DIS profile GeoVrml to GeoSpatial profile X3D design work in progress: - is there some way to apply a restriction that only one child of Collision can have containerField="proxy" ? - Augment H-Anim 1.1 with H-Anim 2001. Decide if 1.1 can be included compatibly (as with DTD). - Using XSV validator to check the internal consistency of the schema. - Matching interfaces with org.w3c.dom Element, Attr and Event types. Mapping to SAI BaseNode, BaseField and Event respectively. Under evaluation as part of Scene Authoring Interface (SAI) development. - Add additional type restrictions such as FloatNonNegative etc. ? Consider whether this can be codified as further base types or included as range restrictions on existing base types. Challenge is getting FloatNonNegative to map to Float externally while still providing range-checking of attribute values. - Can FloatNonNegative pattern restrictions instead be added on a localized node-by-node basis? Probably too verbose, but at least that preserves base-type definitions. - Can deprecations be encoded as allowable options, or alternate/duplicate attributes? Stylesheets can capture and propagate the deprecations if consistently defined. - Can SubstitutionGroup be used for deprecated node labels like LOD-level (now LOD-children) and Switch-choice (now Switch-children)? No. - Patterns for multifield types need to be completed. - Establish different namespace scopes using key/keyRef for DEF/USE ID/IDREFs (and ROUTE/IS) inside ProtoDeclare. - Establish different namespace scopes for node and ProtoDeclare names. - Update the x3d-compact.dtd to precisely match names used for node types (e.g. GroupingNode). - Add source urls for annotations appinfo/documentation once specification addresses are stable. Initially using VRML 97 specification URLs for clarity. Updating to XLink urls into VRML 200x is the eventual goal. - Can USE be substituted anywhere? XML Schema substitutionGroup? Wildcard? Answer: USE no longer allowed due to type ambiguity, redundancy. - Insert namespace prefixes (xsd: etc.) once Xeena editing permits. See next section of this documentation for example implementation details. - How do we allow X3D.profileForContainedScene to contain/return an array of profileName values? Must we create a new type profileNameArray? - Consider optionalAttributes for appropriate fields in Interchange profile nodes that are only guaranteed at higher profile levels (or else just annotate them and leave optional implementation silent as an implementer choice). - Is it possible for this schema to differentiate profile-optional attributes (e.g. Anchor.target, IndexedFaceSet.convex etc.) in the same way that the DTD allows strict or loose checking of different-profile attributes? This is a bit tricky since browsers can optionally support Immersive-related attributes even when operating in a Interchange profile mode. - Relax ROUTE to appear within a scene/prototype, not solely at the end: ROUTE is a child node type. - Interface Base renamed to BaseType for clarity & consistency - May 2002: successfully tested with XML Spy 4.3. Need to automate regression testing for schema-based validation of content suites, a few esoteric schema warnings remain from xsqc and xsv. ============================================================================= Future work with namespaces and 'xsd:' qualifiers for non-X3D schema elements/datatypes, once software tools are namespace aware: xmlns ="http://www.w3.org/2000/10/XMLSchema" xmlns:xsd="http://www.w3.org/2000/10/XMLSchema" xmlns:x3d="http://www.web3D.org/TaskGroups/x3d/translation/X3dSchemaDraft.dtd" targetNamespace="http://www.web3D.org/TaskGroups/x3d/translation/X3dSchemaDraft.dtd" DTD processing approach to namespaces: X3dSchemaDraft.xml entity declaration section (i.e. document subset) which goes inside the DOCTYPE tag at the top of this schema: ] Caution: Xeena and JAXP do not yet support document subset or namespaces, so the preceding document subset fragment listed here will get clobbered if inserted inside DOCTYPE. ============================================================================= XSV validator server: http://www.w3.org/2001/03/webdata/xsv Actual schema public ID: -//W3C//DTD XMLSCHEMA 200102//EN Web address schema DTD: http://www.w3.org/2001/XMLSchema.dtd Local address schema DTD: file://localhost/www.web3D.org/TaskGroups/x3d/translation/XMLSchema.dtd Edited copy X3D schema: C:\www.web3D.org\TaskGroups\x3d\translation\X3dSchemaDraftSpy.xsd Smooth copy X3D schema: C:\www.web3D.org\TaskGroups\x3d\translation\X3dSchemaDraft.xml ============================================================================= ]]> integerList is an internal type for creating lists in the schema, not for author use, that may get refactored away in a future version of the X3D schema. doubleList is an internal type for creating lists in the schema, not for author use, that may get refactored away in a future version of the X3D schema. floatList is an internal type for creating lists in the schema, not for author use, that may get refactored away in a future version of the X3D schema. BoundedNodeType indicates that bounding box values can be provided (or computed) for this node and any children. Bounding box values approximate the volume of a containing box in the current coordinate system. Bounding box values can optionally be provided to (or calculated by) 3D browsers. Bounding box values are hints that can improve performance by allowing browsers to inexpensively cull geometry, thus avoiding the computational cost of trying to drawing shapes when they are outside of the current view. BoundingBoxSize dimensions are non-negative values. Default value (-1 -1 -1) indicates that no bounding box size has been computed. Boolean is a logical type with possible values (true|false) to match the XML boolean type. Boolean is equivalent to type SFBool (TRUE|FALSE) in the VRML Specification. Hint: X3D boolean values are lower case (true|false) in order to maintain compatibility with other XML documents. Booleans is an array of Boolean values. Booleans is analagous to type MFBool, unspecified in the VRML 97 Specification. Hint: Booleans is useful for defining a series of behavior states using a BooleanSequencer prototype. empty or three-tuple of floats range [0..1] Color is equivalent to type SFColor in the VRML 97 Specification. Colors is equivalent to type MFColor in the VRML 97 Specification. Double is a double-precision floating-point type. See GeoVRML 1.0 Recommended Practice, Section 2.3, Limitations Of Single-Precision. Double/Doubles are analagous to SFDouble/MFDouble using VRML specification nomenclature. Doubles is an array of Double values, i.e. a double-precision floating-point array type. See GeoVRML 1.0 Recommended Practice, Section 2.3, Limitations Of Single-Precision. Double/Doubles are analagous to SFDouble/MFDouble using VRML specification nomenclature. Float is a single-precision floating-point type. Float is equivalent to type SFFloat in the VRML 97 Specification. Float is a single-precision floating-point type. Float is equivalent to type SFFloat in the VRML 97 Specification. Float is a single-precision floating-point type. Float is equivalent to type SFFloat in the VRML 97 Specification. Float is a single-precision floating-point type. Float is equivalent to type SFFloat in the VRML 97 Specification. Float is a single-precision floating-point type. Float is equivalent to type SFFloat in the VRML 97 Specification. Floats is an array of Float values, i.e. a single-precision floating-point array type. Floats is equivalent to type MFFloat in the VRML 97 Specification. Image is equivalent to type SFImage in the VRML 97 Specification. Images is an array of Image values. Images is analagous to MFImage using VRML 97 Specification nomenclature. Hint: Images may become a useful type for multitexture imaging. Integer is equivalent to type SFInt32 in the VRML 97 Specification. Integers is an array of Integer values. Integers is equivalent to type MFInt32 in the VRML 97 Specification. Rotation is an axis-angle 4-tuple, indicating X-Y-Z direction plus angle orientation about that axis. Rotation is equivalent to type SFRotation in the VRML 97 Specification. Rotations is an array of Rotation values. Rotations is equivalent to type MFRotation in the VRML 97 Specification. String is equivalent to type SFString in the VRML 97 Specification. Strings is an array of String values. Strings is equivalent to type MFString in the VRML 97 Specification. Time is equivalent to type SFTime in the VRML 97 Specification: (float) seconds since January 1 1970. Null value = -1. Consider constraining values via regex pattern. Times is an array of Time values. Times is equivalent to type MFTime in the VRML 97 Specification. empty or two floats Vector2Float is a 2-tuple pair of Float values. Vector2Float is equivalent to type SFVec2f in the VRML 97 Specification. Hint: Vector2Float can be used to specify a 2D coordinate. empty or array of two-tuple floats Vector2FloatArray is an array of Vector2Float values. Vector2FloatArray is equivalent to type MFVec2f in the VRML 97 Specification. empty or three floats Vector3Float is a 3-tuple triplet of Float values. Vector3Float is equivalent to type SFVec3f in the VRML 97 Specification. Hint: Vector3Float can be used to specify a 3D coordinate or a 3D scale value. Vector3FloatArray is an array of Vector3Float values. Vector3FloatArray is equivalent to type MFVec3f in the VRML 97 Specification. Vector3Double is a 3-tuple triplet of Double values. See GeoVRML 1.0 Recommended Practice, Section 2.3, Limitations Of Single-Precision. Hint: Vector3Double can be used to specify a georeferenced 3D coordinate. Vector3DoubleArray is an array of Vector3Double values. See GeoVRML 1.0 Recommended Practice, Section 2.3, Limitations Of Single-Precision. Hint: Vector3DoubleArray can be used to specify a list of georeferenced 3D coordinates. fieldTypeName contains the names of all BaseField types. profileName enumeration constants are used to identify the profile for each scene-graph node, and also used by X3D tag to identify the profile of a contained Scene. Interchange Profile equals the minimum subset of nodes needed to author lightweight compelling content. Warning: the X3D/VRML 200x Specification is still in very rough form and will be modified to match implementation/evaluation results. Interactive Profile adds interaction nodes (Anchor, KeySensor) to the minimum subset of nodes needed to author lightweight compelling content. Interactive also matches corresponding profile in MPEG-4 Amendment 4. Warning: the X3D/VRML 200x Specification is still in very rough form and will be modified to match implementation/evaluation results. Immersive Profile equals all of the nodes in the VRML 97 Specification, plus VRML 200x node additions including KeySensor, StringSensor and Scene. Warning: the X3D/VRML 200x Specification is still in very rough form and will be modified to match implementation/evaluation results. Extensibility Profile may become a choice for lightweight scripting content; includes Interactive Profile plus a few more nodes. Under development. Warning: the X3D/VRML 200x Specification is still in very rough form and will be modified to match implementation/evaluation results. The Full Profile corresponds to all Immersive VRML nodes plus all approved/implemented extensions. Full may get renamed Integrated. Warning: the X3D/VRML 200x Specification is still in very rough form and will be modified to match implementation/evaluation results. DIS Profile demonstrates how to implement the IEEE Distributed Interactive Simulation (DIS) Protocol with VRML 97/200x for physics-based multi-player distributed virtual environments. GeoVRML 1.0 Recommended Practice for the representation of geographical data in VRML. Humanoid Animation Recommended Practice version 1.1 HumanoidAnimation (H-Anim) is a standard way of representing humanoids in VRML 97. It allows humanoid models created using authoring tools from one vendor to be animated using tools from another. H-Anim humanoids can be animated using keyframing, inverse kinematics, performance animation systems and other techniques. Warning: Lattice Profile implementation is not yet finished. Nurbs are Non-Uniform Rational B-Spline surfaces. Warning: Nurbs Profile is only partially implemented, PrototypeDeclarations are still needed for these nodes. A Nurbs overview is also available at http://www.blaxxun.com/developer/contact/3d/nurbs/overview.html fieldHint allows providing backwards compatibility with VRML 97 for Script and Proto field definitions. Nodes of this type can be used as child nodes for Appearance. Nodes implementing AudioClipNodeType are allowed children of Sound node BaseType is the same as the VRML 97 Field class. BaseField, BaseFieldArray, BaseNode and BaseNodeArray implement BaseType. BaseField is equivalent to SF (Single Field) simple non-Node types in the VRML 97 Specification. BaseFieldArray is equivalent to MF (Multiple Field) simple non-Node types in the VRML 97 Specification. All instantiable nodes implement BaseNode, which corresponds to SFNode in the VRML 97 specification. Default fixed value for profile can be overridden by implementing nodes and node types. BaseNodeArray corresponds to MFNode in the VRML 97 specification. Bindable nodes implement the binding stack, so that only one of each node type is active at a given time. BoundedNodeType indicates that bounding box values can be provided (or computed) for this node and any children. Bounding box values approximate the volume of a containing box in the current coordinate system. Bounding box values can optionally be provided to (or calculated by) 3D browsers. Bounding box values are hints that can improve performance by allowing browsers to inexpensively cull geometry, thus avoiding the computational cost of trying to drawing shapes when they are outside of the current view. A node that implements ChildNodeType is one of the legal children for a GroupingNodeType parent. ContainedNodeLabel tags help distinguish between the different uses of node siblings that might otherwise share the same node type. These tags are labels in the scene graph, not instantiable nodes. Because these tags do not need to be instantiated as scene graph nodes, they do not have DEF or USE values like BaseNodes. ContainedNodeLabel tags are sometimes referred to as "wrapper tags." Note that ContainedNodeLabel tags are not needed when node siblings have different types. Thus "wrapper tags" are not needed for most child nodes in the VRML 97 node set. An Event consists of a timeStampX3d and a field value. An event is a message sent from one node to another, connecting fields as defined by a ROUTE. Events signal external stimuli, changes to field values, and interactions between nodes. Note existence of related and equivalent org.w3c.dom.events.Event.timeStamp. Geometry nodes produce renderable geometry and are contained by a Shape node. Grouping nodes can contain other nodes as children, thus making up the backbone of a scene graph. Interpolator nodes are designed for linear keyframed animation. Interpolators are driven by an input key ranging [0..1] and produce corresponding piecewise-linear output functions. Light nodes provide illumination for rendering geometry in the scene. SceneGraphStructureNodeType is a marker interface that identifies nonrenderable nodes relating to scene graph structure. SceneGraphStructureNodeType extends from Base rather than BaseNode since DEF/USE not appropriate for declarations. This complexType will likely not be needed, since integrating ProtoInstance into the content models solves the wildcard and extensibility problems. Child-node content model corresponding to AppearanceChildNodeType. Can't be split into Interchange/Interactive/Immersive due to use of xsd:all. Incorporation of ProtoDeclare/USE constraints for each node is pretty clumsy, perhaps xsd:substitution is an alternative. Still need fine-grained substibution of ProtoInstance and USE. Child-node content model corresponding to ChildNodeType, combining all profiles. Child-node content model corresponding to ChildNodeType, combining all profiles. Child-node content model corresponding to ChildNodeType for Interchange profile. Child-node content model corresponding to ChildNodeType for Interactive profile. Child-node content model corresponding to ChildNodeType for Base profile. Child-node content model corresponding to ChildNodeType for DIS profile. Child-node content model corresponding to ChildNodeType for GeoSpatial profile. Child-node content model corresponding to ChildNodeType for HumanoidAnimation profile. Child-node content model corresponding to ChildNodeType for Nurbs profile. Child-node content model corresponding to IndexedLineSet and PointSet. Child-node content model corresponding to ElevationGrid, GeoElevationGrid. ProtoInstance/USE wildcards not yet working. Child-node content model corresponding to ElevationGrid. Child-node content model corresponding to GeometryNodeType, combining all profiles - select only one total. Includes ProtoInstance, USE options. Child-node content model corresponding to GeometryNodeType for Interchange profile. Child-node content model corresponding to GeometryNodeType for Base profile. Child-node content model corresponding to GeometryNodeType for GeoSpatial profile. Child-node content model corresponding to GeometryNodeType for Nurbs profile. Child-node content model corresponding to a valid scene-graph fragment. Can provide field or fieldValue initialization, so no ROUTEs or prototype declarations allowed. Child-node content model corresponding to a valid scene-graph fragment. Also includes ROUTE(s) and prototype declaration(s). Child-node content model corresponding to ShapeNodeType. Child-node content model corresponding to SoundNodeType. Child-node content model corresponding to TextNodeType. Color node renamed ColorNode in order to avoid an interface collision with the Color field type for RGB values. field can contain either attribute-value or node content. field is used by ExternProtoDeclare, ProtoDeclare and Script nodes. fieldValue can contain either attribute-value or node content. fieldValue is used by ProtoInstance nodes, reinitializing default values specified in ProtoDeclare field tags. Nested ProtoDeclares, ProtoInstances are allowed by specification. Nested ProtoDeclares, ProtoInstances are allowed by specification. ProtoInstance contained content normally captured via fieldValue initializations. ROUTEs can also be added or removed via the Scene node, or via a ProtoDeclare node. Global Coordinate System (GeoMetadata node only) Geodetic Geocentric Equatorial Inertial Geocentric Solar Ecliptic (GeoMetadata node only) Geocentric Solar Magnetospheric (GeoMetadata node only) Lambert Conformal Conic PCS (GeoMetadata node only) Local Space Rectangular (GeoMetadata node only) Polar Stereographic PCS (GeoMetadata node only) Solar Magnetic (GeoMetadata node only) Transverse Mercator (GeoMetadata node only) Universal Transverse Mercator (GeoMetadata node only) HumanoidNodeType enables extensibility for the Humanoid node.