This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.web3d.org/x3d/specifications/ISO-IEC-FDIS-19776-1.2-X3DEncodings-XML/Part01/X3D_XML.html Like SVG, X3D can be embedded in XHTML, contains void elements, and makes use of mixed case elements and attributes. For purposes of helping to understand the impact of section 9.2.5.1 (<http://dev.w3.org/html5/spec/syntax.html#creating-and-inserting-elements>), I've produced a list of such elements and attributes: Mixed case: Elements: AllTextureNodes AllTextureTransformNodes AppearanceChildNodes AppearanceNodeExtensions AppearanceNodes AudioClipNodeExtensions AudioClipNodes BehaviorLeafNodes BindableNodeExtensions BindableNodes CadComponent CadGeometryNodes CadGroupingNodes ChildrenNodes ColorCoordinateNormalTextureCoordinateContentModel ColorNodeExtensions ColorNodes ComposedGeometryNodes CoordinateNodeExtensions CoordinateNodes CubeMapTextureNodes CubeMapTexturingComponent DISComponent DISGroupingNodes DisplacerNode DragSensors EnvironmentalSensorNodes EventUtilityNodeExtensions EventUtilityNodes FollowerNodes FollowersComponent FontStyleNodeExtensions FontStyleNodes FullProfile GeoBehaviorNodes GeoCoordinateNode GeoElevationGridNode GeoGroupingNodes GeoMetadataNode GeoOriginNode GeoSpatialComponent GeoViewpointNode Geometry2DNodes GeometryNodeExtensions GeometryNodes GroupingNodeExtensions GroupingNodes HAnimComponent HAnimGroupingNodes ImmersiveProfile InteractiveProfile InterchangeProfile InterpolatorNodeExtensions InterpolatorNodes JointNames KeyDeviceSensors LanguageCode LatticeXvlComponent LayeringComponent LayoutComponent LightNodeExtensions LightNodes MFBool MFColor MFColorRGBA MFDouble MFFloat MFImage MFInt32 MFMatrix3d MFMatrix3f MFMatrix4d MFMatrix4f MFRotation MFString MFTime MFVec2d MFVec2f MFVec3d MFVec3f MFVec4d MFVec4f MaterialNodeExtensions MaterialNodes MetadataNodeExtensions MetadataNodes MovieTextureNodeExtensions MovieTextureNodes MultiTextureChildTextures NetworkSensorNodeExtensions NetworkSensorNodes NormalNodeExtensions NormalNodes NurbsComponent NurbsControlCurveNodes NurbsGeometryNodes NurbsInterpolators OtherLeafNodes ParticleSystemsComponent PickingSensorComponent PointingDeviceSensors ProtoNodes RigidBodyPhysicsComponent RigidBodyPhysicsGroupingNodes SFBool SFColor SFColorRGBA SFDouble SFFloat SFImage SFInt32 SFMatrix3d SFMatrix3f SFMatrix4d SFMatrix4f SFRotation SFString SFTime SFVec2d SFVec2f SFVec3d SFVec3f SFVec4d SFVec4f SceneLeafNodes SceneNodes ScriptNodeExtensions ScriptNodes SensorNodeExtensions SensorNodes ShaderAttributeNodes ShaderNodes ShadersComponent ShapeNodeExtensions ShapeNodes SoundNodeExtensions SoundNodes Texture2DNodes Texture3DComponent Texture3DTextureCoordinateNodes Texture3DTextureNodes Texture3DTextureTransformNodes TextureCoordinateGeneratorModes TextureCoordinateNodeExtensions TextureCoordinateNodes TextureNodeExtensions TextureTransformNodeExtensions TextureTransformNodes TimeDependentNodes Web3dExtensionComponent Web3dExtensionGeometryNodes Web3dExtensionGroupingNodes Web3dExtensionsPrivateDTD Web3dExtensionsPublicDTD WildcardNodes WorldInfoNodeExtensions WorldInfoNodes X3dExtensions X3dFieldTypes X3dInputOutputFields XvlG1T1ShellTypes XvlShell componentLevels componentNames profileNames Attributes: AS DEF USE accessType actionKeyPress actionKeyRelease activeLayer altKey ambientIntensity anchorPoint angularDampingFactor angularVelocity anisotropicDegree antennaLocation antennaPatternLength antennaPatternType applicationID appliedParameters articulationParameterArray articulationParameterChangeIndicatorArray articulationParameterCount articulationParameterDesignatorArray articulationParameterIdPartAttachedToArray articulationParameterTypeArray articulationParameterValue0_changed articulationParameterValue1_changed articulationParameterValue2_changed articulationParameterValue3_changed articulationParameterValue4_changed articulationParameterValue5_changed articulationParameterValue6_changed articulationParameterValue7_changed autoCalc autoDamp autoDisable autoOffset avatarSize axis1Angle axis1Torque axis2Angle axis2Torque axis3Angle axis3Torque axisOfRotation backAmbientIntensity backDiffuseColor backEmissiveColor backShininess backSpecularColor backTransparency backUrl bboxCenter bboxSize beamWidth beginCap bindTime borderColor borderWidth bottomRadius bottomUrl boundaryModeR boundaryModeS boundaryModeT centerOfMass centerOfRotation centerOfRotation_changed child1Url child2Url child3Url child4Url clipBoundary closureType collideTime collisionType colorIndex colorKey colorPerVertex constantForceMix contactNormal contactSurfaceThickness containerField controlKey controlPoint coordIndex creaseAngle createParticles crossSection cryptoKeyID cryptoSystem cutOffAngle cycleInterval cycleTime dataLength deadReckoning deletionAllowed desiredAngularVelocity1 desiredAngularVelocity2 detonateTime detonationLocation detonationRelativeLocation detonationResult diffuseColor directOutput disableAngularSpeed disableLinearSpeed disableTime diskAngle edgeBeginCoordIndex edgeBeginVector edgeEndCoordIndex edgeEndVector edgeRound elapsedTime emissiveColor enabledAxes encodingScheme endAngle endCap enterTime enteredText entityCategory entityCountry entityDomain entityExtra entityID entityKind entitySpecific entitySubCategory errorCorrection eventApplicationID eventEntityID eventNumber eventSiteID exitTime faceCoordIndex faceEmpty faceHidden faceTexCoordIndex fanCount fieldOfView finalText finiteRotationAxis fireMissionIndex firedTime firingRange firingRate fogType forceID forceTransitions frictionCoefficients frictionDirection fromField fromNode frontUrl generateMipMaps geoCenter geoCoords geoGridOrigin geoSystem geometryType groundAngle groundColor hatchColor hatchStyle hitGeoCoord_changed hitNormal_changed hitPoint_changed hitTexCoord_changed importedDEF initialDestination initialValue inlineDEF innerRadius inputFalse inputNegate inputSource inputTrue integerKey intersectionType isActive isBound isCollided isDetonated isLoaded isNetworkReader isNetworkWriter isOver isPaused isPickable isRtpHeaderHeard isSelected isStandAlone isValid keyPress keyRelease keyValue leftToRight leftUrl lengthOfModulationParameters lifetimeVariation limitOrientation lineBounds lineSegments linearAcceleration linearDampingFactor linearVelocity linewidthScaleFactor loadTime localDEF magnificationFilter maxAngle maxAngle1 maxBack maxCorrectionSpeed maxExtent maxFront maxParticles maxPosition maxSeparation maxTorque1 maxTorque2 minAngle minAngle1 minBack minBounceSpeed minFront minPosition minSeparation minificationFilter modulationTypeDetail modulationTypeMajor modulationTypeSpreadSpectrum modulationTypeSystem momentsOfInertia motor1Axis motor2Axis motor3Axis multicastRelayHost multicastRelayPort munitionApplicationID munitionEndPoint munitionEntityID munitionQuantity munitionSiteID munitionStartPoint mustEvaluate mustOutput navType networkMode nodeField normalIndex normalPerVertex numComponents numberOfDivisions objectType offsetUnits outerRadius particleLifetime particleSize pauseTime pointSize preferAccuracy protoField radioEntityTypeCategory radioEntityTypeCountry radioEntityTypeDomain radioEntityTypeKind radioEntityTypeNomenclature radioEntityTypeNomenclatureVersion radioID readInterval receivedPower receiverState relativeAntennaLocation repeatR repeatS repeatT resumeTime retainUserOffsets rightUrl rootUrl rotateYUp rtpHeaderExpected sampleRate scaleMode scaleOrientation separateBackColor set_articulationParameterValue0 set_articulationParameterValue1 set_articulationParameterValue2 set_articulationParameterValue3 set_articulationParameterValue4 set_articulationParameterValue5 set_articulationParameterValue6 set_articulationParameterValue7 set_colorIndex set_coordIndex set_crossSection set_normalIndex set_texCoordIndex set_triggerTime shellType shiftKey siteID sizeUnits skinCoordIndex skinCoordWeight skyAngle skyColor slipCoefficients slipFactors softnessConstantForceMix softnessErrorCorrection sortOrder specularColor speedFactor startAngle startTime stop1Bounce stop1ErrorCorrection stop2Bounce stop2ErrorCorrection stop3Bounce stop3ErrorCorrection stopBounce stopBounce1 stopConstantForceMix1 stopErrorCorrection stopErrorCorrection1 stopTime stripCount surfaceArea surfaceSpeed suspensionErrorCorrection suspensionForce tdlType tessellationScale texCoordIndex texCoordKey textBounds textureCompression texturePriority timeOut toField toNode topToBottom topUrl touchTime trackPoint_changed transitionComplete transitionTime transitionType transmitFrequencyBandwidth transmitState transmitterApplicationID transmitterEntityID transmitterRadioID transmitterSiteID triggerTime triggerTrue triggerValue uClosed uDimension uKnot uOrder uTessellation useFiniteRotation useGeometry useGlobalGravity vClosed vDimension vKnot vOrder vTessellation vertexCount vertexRound visibilityLimit visibilityRange whichChoice whichGeometry writeInterval xDimension xSpacing yScale zDimension zSpacing Pure lower: Elements: i18n Attributes: activate address align alpha angle appinfo applied attenuation axis axis1 axis2 bottom bounce category ccw center class closed color content convex country data depth description direction displacements displayed documentation domain duration duration_changed enabled extra family filled fired1 fired2 fixed force forces fraction_changed frequency function fuse geovalue_changed global gravity gustiness hatched headlight height horizontal http image index inertia info intensity iterations jump justify key kind knot language length level level_changed linetype llimit load location loop marking mass matrix mode name next normal_changed offset on order orientation orientation_changed parameter pickable pitch point port position position_changed power previous priority profile progress radius range reference rotation rotation_changed samples scale scheme set_bind set_boolean set_fraction set_height set_index set_orientation set_position set_scale set_spine shininess side size solid source spacing spatialize specific speed spine stiffness string style subcategory summary tau tessellation time timestamp title toggle tolerance top torques translation translation_changed transparency turbulence type ulimit update url value value_changed variation vector version vertices visible warhead weight xmlns xsd
Related discussion: http://lists.w3.org/Archives/Public/public-html/2009Nov/0206.html
It would be helpful to convert this bug report to a more specific request.
(In reply to comment #2) > It would be helpful to convert this bug report to a more specific request. Maciej, can you explain what you perceive to be missing? Meanwhile, I'll restate the request as follows: the request is for embedded X3D grammars to be parsed into the DOM in a way that matches what is produced when the same grammar is included in XHTML. As background, the current spec causes the parser to go into a different mode when an element whose name matches "math" or "svg" is encountered. This affects the namespace of the associated and nested elements, causes trailing solidus characters in start element tag syntax to be interpreted as void elements, and causes a number of element and attribute names to be fixed up to be mixed case. Doing the same for X3D would address this request. The referenced email describes an alternate approach which would work for all elements but the "i18n" element in X3D. It would not recover properly from cases where a non-well-formed X3D fragment is included in a larger document which consists of HTML elements in ALL CAPS (something that is conforming, but increasingly rare), but at least all conforming HTML5 parsers would recover consistently.
(In reply to comment #3) > (In reply to comment #2) > > It would be helpful to convert this bug report to a more specific request. > > Maciej, can you explain what you perceive to be missing? The original bug report consisted of the summary "Add support for X3D", linked to the X3D spec, and included a list of elements and attributes. Maybe I'm lacking context, but that did not seem very specific. What counts as "support"? > Meanwhile, I'll restate the request as follows: the request is for embedded X3D > grammars to be parsed into the DOM in a way that matches what is produced when > the same grammar is included in XHTML. That's much more specific. Thank you. Some comments on your proposed alternatives: > > As background, the current spec causes the parser to go into a different mode > when an element whose name matches "math" or "svg" is encountered. This > affects the namespace of the associated and nested elements, causes trailing > solidus characters in start element tag syntax to be interpreted as void > elements, and causes a number of element and attribute names to be fixed up to > be mixed case. Doing the same for X3D would address this request. Tentatively, I would not be in favor of an X3D-specific mechanism in the parser. X3D is not supported directly by UAs, and it's not clear if it ever will be (since there are competing 3D model serializations with similar or greater levels of traction). It should also be noted that purely script-based solutions can fix up the parsing just as easily as they can implement the rendering. With my browser implementor hat on, implementing a significant extra parsing complexity in browsers solely for a single feature that will only be implemented by script- or plugin-based add-ons does not seem like a good tradeoff. > > The referenced email describes an alternate approach which would work for all > elements but the "i18n" element in X3D. It would not recover properly from > cases where a non-well-formed X3D fragment is included in a larger document > which consists of HTML elements in ALL CAPS (something that is conforming, but > increasingly rare), but at least all conforming HTML5 parsers would recover > consistently. If I understand correctly, the root element of X3D is not mixed case ("X3D" only has capital letters), so it doesn't seem like the email proposal satisfies your request. Interesting idea though. [Side note: I may be misunderstanding the X3D spec here, but the spec doesn't seem to state a namespace URI for X3D, and none of the examples have a default namespace declaration on the root element. Is X3D actually in a namespace?]
They usually use noNamespaceSchemaLocation, since they believe (as mentioned in http://www.web3d.org/x3d/publiclists/x3dpublic_list_archives/0712/msg00130.html and a few other places, basically wherever this question comes up) specifying a schema entails namespacing and only for integration with other XML vocabularies do they care about satisfying the formal requirement of making it explicit, in which case they suggest xmlns:prefix="schema-URI", i.e. the namespace name is identical to the schema's URI. This belief is an interpretation which has been suitable so far for that community but it isn't shared by people outside of it, so as the right way forward I see asking them to specify that namespace in the next version of their XML encoding. (It seems that so far only individuals have done that, so it hasn't gained enough priority within their work.)
(In reply to comment #4) > > With my browser implementor hat on, implementing a significant extra parsing > complexity in browsers solely for a single feature that will only be > implemented by script- or plugin-based add-ons does not seem like a good > tradeoff. Void elements pose a significant problem. That data, once lost, is generally impossible to reconstruct. > If I understand correctly, the root element of X3D is not mixed case ("X3D" > only has capital letters), so it doesn't seem like the email proposal satisfies > your request. Interesting idea though. I was imprecise. I meant elements which contain at least one capital letter.
(In reply to comment #4) > X3D is not supported directly by UAs, and it's not clear if it ever > will be (since there are competing 3D model serializations with similar or > greater levels of traction). It should also be noted that purely script-based > solutions can fix up the parsing just as easily as they can implement the > rendering. Maybe it should also be noted that if script-based solutions act on a certain style of X3D-in-HTML markup, then it is likely that UAs would never be able to directly support X3D with the same markup, else they would break content that relies on the script-based solution. An alternate solution specifically provided by HTML5 for embedding data to be processed by scripts is <script type="model/x3d+xml"><X3D>...</X3D></script>. That has its own drawbacks but may be worth considering, if the data benefits from being inline in the HTML page.
(In reply to comment #6) > (In reply to comment #4) > > > > With my browser implementor hat on, implementing a significant extra parsing > > complexity in browsers solely for a single feature that will only be > > implemented by script- or plugin-based add-ons does not seem like a good > > tradeoff. > > Void elements pose a significant problem. That data, once lost, is generally > impossible to reconstruct. That certainly complicates things for anyone wishing to put XML vocabularies in HTML (it would require explicitly closing empty elements or putting the content in an inline <script> to avoid parsing). But it doesn't make me, as a UA implementor, feel more motivated to add built-in parsing complexity for a feature to be implemented by third-part code. > > > If I understand correctly, the root element of X3D is not mixed case ("X3D" > > only has capital letters), so it doesn't seem like the email proposal satisfies > > your request. Interesting idea though. > > I was imprecise. I meant elements which contain at least one capital letter. > That seems like it would be more likely to work for X3D. But it may also have slightly greater compatibility risk. The email suggestion also mentions mixed-case elements and slash-based self-closing syntax being supported. But although an xmlns attribute is one of the triggers, it does not mention applying namespace processing. Was that intended?
(In reply to comment #5) > They usually use noNamespaceSchemaLocation, since they believe (as mentioned in > http://www.web3d.org/x3d/publiclists/x3dpublic_list_archives/0712/msg00130.html > and a few other places, basically wherever this question comes up) specifying a > schema entails namespacing and only for integration with other XML vocabularies > do they care about satisfying the formal requirement of making it explicit, in > which case they suggest xmlns:prefix="schema-URI", i.e. the namespace name is > identical to the schema's URI. This belief is an interpretation which has been > suitable so far for that community but it isn't shared by people outside of it, > so as the right way forward I see asking them to specify that namespace in the > next version of their XML encoding. (It seems that so far only individuals have > done that, so it hasn't gained enough priority within their work.) > That seems like a problematic approach. Indeed it would be good to explicitly specify the namespace URI. It would also be good if the namespace URI did not change with the version of the spec - googling around, I found a number of different schema-based namespace URIs.
There are some problems in the list of elements and attributes. All of the listed elements that end with 'Nodes' or 'Extensions' are actually abstract types and do not appear in scene content. So these should be excluded. All of the listed elements beginning with 'SF' or 'MF' are actually enumerations for field types. They are not elements or attributes. All of the listed elements beginning with 'Profile' or 'Profile' are actually enumerations for profile names. They are not elements or attributes. A correction to the list of attributes there: we do not have an element or attribute named 'i18n'. A few other enumeration arrays have also crept in: 'JointNames', 'LanguageCodes', 'X3dInputOutputFields' and a few others. All of these should be excluded. All the rest appear to be OK. A current list of element and attribute names is found on the X3D Tooltips page. http://www.web3d.org/x3d/content/examples/X3dResources.html#tooltips If you wish, I can take an action to autogenerate a precise list from the X3D Schema itself. http://www.web3d.org/specifications http://www.web3d.org/specifications/x3d-3.2.xsd In other words, we also think that it is viable to follow Sam's suggested path: "embedded X3D grammars to be parsed into the DOM in a way that matches what is produced when the same grammar is included in XHTML." Another reponse: we will be happy to comply with the sense of comment #5 to align namespaces using best practices in whatever way the HTML5 group recommends. Deeper issues from an X3D perspective are that each X3D field (attribute) is defined to have both a complexType and also an accessType. Allowed accessType enumerations are inputOnly, outputOnly, initializeOnly and inputOutput. Routing X3D events can optionally prepend 'set_' for input event names, and append '_changed' for output event names. These are optional in X3D; they should be ignored and avoided in HTML5. This approach can reconcile the minor differences in the two event models. We also discussed persistent state. There are some internal restrictions in X3D that are intended to improve run-time performance in large scenes. These persistence and state-related restrictions can be ignored in a DOM tree without breaking the reconciliation of the event models. Deferred issue: we will look at 'void elements' issues next time we talk. In general, the only contained content in any element is (optionally) embedded source code in Script of *Shader nodes. All other numeric or text content for an X3D scene graph is captured within attribute values.
corrected tooltip links: http://www.web3d.org/x3d/content/examples/X3dResources.html#Tooltips (multiple languages) http://www.web3d.org/x3d/content/X3dTooltips.html (X3D v3.2, English)
If we don't want to change the HTML parser, X3D *could* bend over backwards and change the namespace of elements to the XHTML namespace and the case of elements and attributes to all-lowercase, and drop <Script>, <head>, <meta>. X3D has some element names that future versions of HTML might want to use, such as <Contact>. This may or may not be an issue, but a way to resolve it is to prefix all X3D elements with something, e.g. "x" or "x3d". I'm not saying this is a good idea, just stating a possible alternative.
Design note: X3D adopted <head> and <meta> exactly from HTML to ensure bot familiarity for web authors and compatibility for metadata recorded in documents.
(In reply to comment #4) > ... > Tentatively, I would not be in favor of an X3D-specific mechanism in the > parser. X3D is not supported directly by UAs, and it's not clear if it ever > will be (since there are competing 3D model serializations with similar or > greater levels of traction). It should also be noted that purely script-based > solutions can fix up the parsing just as easily as they can implement the > rendering. > ... http://www.x3dom.org/?page_id=9 seems to imply that support for it is planned both in Mozilla and Webkit...
(In reply to comment #14) > http://www.x3dom.org/?page_id=9 seems to imply that support for it is planned > both in Mozilla and Webkit... No, it just says that WebGL is supported in Firefox and WebKit nightly builds. (WebGL is not X3D.)
(In reply to comment #15) > (In reply to comment #14) > > http://www.x3dom.org/?page_id=9 seems to imply that support for it is planned > > both in Mozilla and Webkit... > > No, it just says that WebGL is supported in Firefox and WebKit nightly builds. > (WebGL is not X3D.) My Firefox trunk build over here supports the markup that Sam Ruby has posted at http://intertwingly.net/blog/2009/11/05/Web3D. So are you saying that is not X3D, or that Webkit implements something else (a subset?)?
(In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #14) > > > http://www.x3dom.org/?page_id=9 seems to imply that support for it is planned > > > both in Mozilla and Webkit... > > > > No, it just says that WebGL is supported in Firefox and WebKit nightly builds. > > (WebGL is not X3D.) > > My Firefox trunk build over here supports the markup that Sam Ruby has posted > at http://intertwingly.net/blog/2009/11/05/Web3D. So are you saying that is not > X3D, or that Webkit implements something else (a subset?)? That page is XHTML5, and makes use of a script to interpret the markup: http://intertwingly.net/stories/2009/11/05/x3dom.js
> That page is XHTML5, and makes use of a script to interpret the markup: > > http://intertwingly.net/stories/2009/11/05/x3dom.js Aha. Thanks for the clarification.
I think this bug should be resolved as WONTFIX. Principled arguments: * We are way past the feature freeze for HTML5. * I think HTML parsing shouldn't be changed to cater to any most-favored JavaScript library. Practical arguments: * Case fixups either bloat the data footprint of the HTML parser or cause more branching at run time. This is somewhat justified for SVG, because 3 out of the top 4 browsers already supported the above-DOM parts of SVG. However, when a vocabulary isn't already natively supported by browsers, we are in a position not to accept this complication again. * In the case of the HTML5 parser in Gecko, the most frequent complaints I get from other developers pertain to the large tables of named characters and to the large tables of known element and attribute names. Bloating those tables only to benefit a most-favored JS library (as opposed to catering to a new Gecko-native feature) seems unattractive. * The alternative tableless idea from http://lists.w3.org/Archives/Public/public-html/2009Nov/0206.html would require deoptimizing the tokenizer compared to what element and attribute name early interning and early case folding optimizations are now possible. I think it doesn't make sense to deoptimize anything in the parser just to cater to a most-favored JS library. * If X3D models tend to be large enough to make considering EXI relevant (see http://lists.w3.org/Archives/Public/public-html/2009Nov/0120.html), surely it doesn't make sense to inline the models (except for small demos) into text/html. When a JS library uses external models and renders them using WebGL, the library could retrieve the XML-serialized models using XHR without any need for changes in the HTML parser. (For example, you could use <canvas data-x3d-src='url-to-.x3d-file'>...</canvas> in markup and have the JS library activate when it finds data-x3d-src, retrieve the model using XHR and render to the canvas using WebGL.)
Opera does not plan to implement X3D, thus don't want X3D-specific parsing in text/html. It's also not clear to me that it's desirable to have X3D inline in text/html rather than as an external file.
Here is a new table listing all X3D v3.2 elements and attributes, first column XML case and second column lowercase. This is needed as part of our in-progress response to the HTML5 working group on how to support X3D in the draft HTML5 Recommendation. Double-checks of this table of values are welcome. It should show unambiguous 2-way mappings (meaning no name collisions between elements or attributes that differ only by case). The table is created by an XSLT stylesheet that uses the official X3D v3.2 schema as input. Everything has been checked into Sourceforge. Autogenerated table: http://x3d.svn.sourceforge.net/viewvc/x3d/www.web3d.org/x3d/stylesheets/X3dElementsAttributesLowerCaseTable.txt Stylesheet: http://x3d.svn.sourceforge.net/viewvc/x3d/www.web3d.org/x3d/stylesheets/X3dElementsAttributesLowerCaseTableConstruction.xslt Invoking build to run this stylesheet (task html5.buildElementsAttributesTable) http://x3d.svn.sourceforge.net/viewvc/x3d/www.web3d.org/x3d/stylesheets/build.xml Incidentally I was able to create, build, test and checkin everything solely using X3D-Edit. 8) https://savage.nps.edu/X3D-Edit
(In reply to comment #21) The X3D v3.2 and related schemas used to generate these lists are available online at http://www.web3d.org/specifications http://x3d.svn.sourceforge.net/viewvc/x3d/www.web3d.org/specifications http://www.web3d.org/specifications/x3d-3.2.xsd http://x3d.svn.sourceforge.net/viewvc/x3d/www.web3d.org/specifications/x3d-3.2.xsd http://www.web3d.org/specifications/X3dSchemaDocumentation3.2/x3d-3.2.html
Don, did you mean to assign this bug to yourself? It won't appear on my radar if it isn't assigned to me or the default assignee. Please advise.
Assuming the self-assignment was in error.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: Given comment 19 and comment 20, and similar feedback that I've received off-bug from other vendors, I'm reluctant to add this to HTML5 at this time. Could you clarify which vendors are interested in implementing this in their HTML UAs? Without a commitment to implement this, it seems premature to add it to the spec.
We have solicited first-person interest from different UA vendors with little feedback so far. Further dialog is welcome. We have closely examined the Mozilla Minefield and Apple Safari /Google Chrome Webkit implementations. We have further created a plugin-free implementation that works with each codebase for compound HTML/X3D documents, using an HTML script that invokes a WebGL library to parse embedded X3D. This open-source solution is documented and demonstrated at http://www.x3dom.org We are prepared to go beyond this, to develop and contribute code that integrates an open-source X3D player directly with these HTML UA browsers. This would appear to provide the native capability in three browsers. We further remain keen to collaborate with Opera and Microsoft. Of additional technical interest is that this aproach might be repeated for a DirectX-based renderer, or even a different shader-based renderer such as Google O3D. Given that 3 or more major HTML user agents might be demonstrated capable of handling centralized extensibility of X3D in HTML5, this commitment seems sufficient to handle this important requirement.
The X3DOM experiment (http://x3dom.org) is a great proof-of-concept that X3D, as well as many other declarative 3D formats, can be accommodated in HTML 5 today without additional parsing in the browser. The reason for adding WebGL to WebKit and other browsers was to include the smallest set of 3D functionality possible and avoid locking in any one higher-level scene-based format. This both makes the implementation tractable and reliable as well as making it implementable on a wide array of devices. X3D is only one scene-based 3D format. There are many others that will surely arise using the same WebGL based mechanism as X3DOM. Some will have a large set of wide ranging nodes like X3D, others will be much smaller, targeted at specific applications like games of 3D visualization. The beauty of WebGL is that is can accommodate all these formats without the burden of building any of them into the browser. I worked on VRML, the predecessor to X3D, from its inception in 1994 to 2000. I was one of the authors of the VRML 97 ISO spec and I'm editor of the WebGL spec now. I've seen lots of cool and interesting things with 3D embedded content and I'm convinced that keeping the native 3D browser support as small and lean as possible is the right approach to enable X3D and many other 3D apps in the browser. With my WebKit implementor's hat on I can say that we wouldn't be interested in adding native X3D parsing to WebKit. But I would be extremely interested in seeing the X3D group put effort into improving X3DOM and creating other JavaScript layers on top of WebGL. I think there is huge potential there for all the 3D applications the X3D group is currently pursuing.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: Without commitments from multiple browser vendors to implement this, I don't think we should add it to the language.