XML Schema for the Extensible 3D (X3D) Graphics Specification tagset 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 - Wrapper tag issues: http://www.web3D.org/TaskGroups/x3d/ComposingSceneGraphAlternatives.html - Color: naming collision between X3DField 'color' and node interface 'Color' avoided by distinct naming conventions for field type and field name. ============================================================================= ---Recheck--- X3D design work in progress: - How to identify simple types as X3DField and X3DArrayField? - Need 2D nodes, new nodes - Need X3DTexture3DNode? Probably keep Extrusion, [Geo]ElevationGrid as X3DGeometryNode - Need regex patterns for SFVec2d, MFVec2d, SFVec3d, MFVec3d, MFVec3f, BoundingBoxSize - Need constraint or pattern on TriangleFanSet fanCount and TriangleStripSet stripCount (3 or more values) - Need boundary constraint restrictions - 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 X3DNode, X3DField 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 Base 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. X3DBoundedObject 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. SFBool is a logical type with possible values (true|false) to match the XML boolean type. Hint: X3D SFBool values are lower case (true|false) in order to maintain compatibility with other XML documents. MFBool is an array of Boolean values. Type MFBool was unspecified in the VRML 97 Specification, but nevertheless needed for event utilities and scripting. Hint: MFBool is useful for defining a series of behavior states using a BooleanSequencer prototype. Color is equivalent to type SFColor in the VRML 97 Specification. MFColor is equivalent to type MFColor in the VRML 97 Specification. SFDouble is a double-precision floating-point type. See GeoVRML 1.0 Recommended Practice, Section 2.3, Limitations Of Single-Precision. MFDouble 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. SFDouble/MFDouble are analagous to SFDouble/MFDouble using VRML specification nomenclature. SFFloat is a single-precision floating-point type. MFFloat is an array of SFFloat values, i.e. a single-precision floating-point array type. MFImage is an array of SFImage values. MFInt32 is an array of Integer values. SFRotation is an axis-angle 4-tuple, indicating X-Y-Z direction plus angle orientation about that axis. MFRotation is an array of SFRotation values. MFString is an array of SFString values. MFTime is an array of SFTime values. SFVec2d is a 2-tuple pair of SFDouble values. Hint: SFVec2d can be used to specify a 2D coordinate. MFVec2d is an array of SFVec2d values. SFVec2f is a 2-tuple pair of SFFloat values. SFVec2f is equivalent to type SFVec2f in the VRML 97 Specification. Hint: SFVec2f can be used to specify a 2D coordinate. MFVec2f is an array of SFVec2f values. MFVec2f is equivalent to type MFVec2f in the VRML 97 Specification. SFVec3d is a 3-tuple triplet of SFDouble values. See GeoVRML 1.0 Recommended Practice, Section 2.3, Limitations Of Single-Precision. Hint: SFVec3d can be used to specify a georeferenced 3D coordinate. MFVec3d is an array of SFVec3d values. See GeoVRML 1.0 Recommended Practice, Section 2.3, Limitations Of Single-Precision. Hint: MFVec3d can be used to specify a list of georeferenced 3D coordinates. SFVec3f is a 3-tuple triplet of SFFloat values. SFVec3f is equivalent to type SFVec3f in the VRML 97 Specification. Hint: SFVec3f can be used to specify a 3D coordinate or a 3D scale value. MFVec3f is an array of SFVec3f values. MFVec3f is equivalent to type MFVec3f in the VRML 97 Specification. fieldTypeName contains the names of all X3DField 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. Core Profile includes no nodes and is available for custom componentization. Interchange Profile equals the minimum subset of nodes needed to author lightweight compelling content. 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. Immersive Profile equals all of the nodes in the VRML 97 Specification, plus VRML 200x node additions including KeySensor, StringSensor and Scene. Extensibility Profile may become a choice for lightweight scripting content; includes Interactive Profile plus a few more nodes. Under development. The Full Profile corresponds to all Immersive VRML nodes plus all approved/implemented extensions. Full may get renamed Integrated. networkModeValues are allowed enumeration values for DIS field networkMode. accessTypeNames are allowed enumeration values for accessType. Prior names in VRML 97 were eventIn, eventOut, field, exposedField respectively. Table of fields having accessType initializeOnly. Table of fields having accessType inputOnly. Table of fields having accessType outputOnly. Table of fields having accessType inputOutput. Nodes of this type can be used as child nodes for Appearance. X3DArrayField is equivalent to MF (Multiple Field) simple non-Node types 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. X3DBoundedObject 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 X3DChildNode is one of the legal children for a X3DGroupingNode parent. X3DField is equivalent to SF (Single Field) simple non-Node types in the VRML 97 Specification. Composed geometry nodes produce renderable geometry, can contain Color Coordinate Normal TextureCoordinate, and are contained by a Shape node. 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. All instantiable nodes implement X3DNode, which corresponds to SFNode in the VRML 97 specification. X3DNodeArray corresponds to MFNode in the VRML 97 specification. Nodes implementing X3DSoundSourceNode are allowed children of Sound node X3DUrlObject indicates that a node has content loaded from a URL and can be tracked via a LoadSensor. 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 X3DNodes. 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. SceneGraphStructureNodeType is a marker interface that identifies nonrenderable nodes relating to scene graph structure. SceneGraphStructureNodeType extends from Base rather than X3DNode 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 X3DAppearanceChildNode. First can contain optional FillProperties and/or LineProperties, then any-order Material, ImageTexture, MovieTexture, MultiTexture, PixelTexture, TextureTransform, MultiTextureTransform. No more than one instance of any single node type. Child-node content model corresponding to X3DChildNode, combining all profiles. Child-node content model corresponding to X3DChildNode for Interchange profile. Child-node content model corresponding to X3DChildNode for Interactive profile. Child-node content model corresponding to X3DChildNode for Immersive profile. Child-node content model corresponding to X3DChildNode for DIS component. Child-node content model corresponding to X3DChildNode for GeoSpatial component. Child-node content model corresponding to X3DChildNode for HumanoidAnimation component. Child-node content model corresponding to X3DChildNode for Nurbs component. Child-node content model corresponding to IndexedLineSet and PointSet. Can contain any-order Coordinate node with Color (or ColorRGBA) node. No more than one instance of any single node type. Child-node content model corresponding to ElevationGrid and GeoElevationGrid. Can contain Color (or ColorRGBA), Normal and TextureCoordinate, in any order. No more than one instance of any single node type. Child-node content model corresponding to IndexedFaceSet: Color (or ColorRGBA), Coordinate, Normal and TextureCoordinate, in any order. No more than one instance of any single node type. Child-node content model corresponding to X3DGeometryNode, combining all components - select only one total. Includes ProtoInstance, USE options. Child-node content model corresponding to X3DGeometryNode for Interchange profile. Child-node content model corresponding to X3DGeometryNode for Immersive profile. Child-node content model corresponding to Geometry2D component. Child-node content model corresponding to X3DGeometryNode for GeoSpatial component. Child-node content model corresponding to X3DGeometryNode for Nurbs component. Child-node content model corresponding to X3DChildNode. Can contain most nodes, other Grouping nodes, Prototype declarations and ProtoInstances in any order and any combination. When less that Full profile, the precise palette of legal nodes depends on profile and components. 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 X3DShapeNode. Can contain single Appearance node and single geometry node, in any order. Child-node content model corresponding to X3DSoundNode. Can contain single AudioClip or MovieTexture as sound source. Child-node content model corresponding to X3DTextNode. Can contain single FontStyle node. Child-node content model corresponding to TextureBackground. Can contain up to six Texture nodes (ImageTexture, MovieTexture, MultiTexture or PixelTexture). Each child texture must have a different containerField for topTexture, bottomTexture, leftTexture, rightTexture, frontTexture and backTexture. 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. Geocentric, Earth-centered, Earth-fixed Geodetic Geocentric Equatorial Inertial (GeoMetadata node only) 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 X3DHumanoidNode enables extensibility for the Humanoid node. http://www.blaxxun.com/support/developerguide/developer/contact/3d/nurbs/spec/nodes.htm#Contour2D http://www.blaxxun.com/support/developerguide/developer/contact/3d/nurbs/spec/nodes.htm#NurbsCurve