Re: X3D comments in Bug 8238.

John A. Stewart wrote:
> Maciej;
> 
> Nice to meet you at the TPAC last week.
> 
> I hope you don't mind; I'm going to bring some of your comments from 
> within Bug 8238 out to the mailing list so that I can ask for 
> clarification.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8238

We discussed this today on our weekly X3D + HTML5 call.  This has also
been pushed onto the bug.

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.

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br           brutzman@nps.edu
Watkins 270   MOVES Institute, Monterey CA 93943-5000 USA  work +1.831.656.2149
X3D, virtual worlds, underwater robots, XMSF  http://web.nps.navy.mil/~brutzman

Received on Tuesday, 17 November 2009 17:09:27 UTC