- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 17 Nov 2009 17:08:34 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8238 Don Brutzman <brutzman@nps.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |brutzman@nps.edu --- Comment #10 from Don Brutzman <brutzman@nps.edu> 2009-11-17 17:08:33 --- 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. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Tuesday, 17 November 2009 17:08:43 UTC