[Bug 8238] Add support for X3D

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