[x3d-public] Minutes for X3D Schema and DTD Review & Refactoring Meeting 25th May 2015

Wed May 27 09:38:37 PDT 2015

Minutes for Schema/DTD Review meeting Monday 25th May 2015 15:00 UTC (08:00
PDT, 16:00 BST)

Attendees:  Don Brutzman, Roy Walmsley

a) Mantis issue 691: Illegal default issues for fields in HAnim component

Issue raised because for HAnimHumanoid node the Schema only accepts the
value "2.0" but the specification default is "", a value that will cause
validation failure.

The relevant specification sections for field 'version' follow. Both list ""
as default value.

X3D 19775-1 26.3.2 HAnimHumanoid
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components
/hanim.html#HAnimHumanoid

H-Anim 19774 6.2 Humanoid
http://www.web3d.org/documents/specifications/19774/V1.0/HAnim/ObjectInterfa
ces.html#Humanoid

... then later in the section says.
==============
The version field stores the version of this International Standard to which
the Humanoid object conforms. The version value for this International
Standard is "2.0".
==============

The historical confusion of the 'version' numbers was explained, and the
need for clearer documentation noted, as follows.

Further description regarding ISO specification and HAnimHumanoid version
numbers can be found in slides 7, 9-11 and 53 of 'X3D for Advanced Modeling
slideset Humanoid Animation (H-Anim) Component':
http://x3dgraphics.com/slidesets/X3dForAdvancedModeling/HumanoidAnimation.pd
f

Problems:
(a) Past humanoid version 1.0 was not compatible with the 2.0 X3D Schema/DTD
and
thus cannot be integrated for validation there. Scene conversion from
version 1.0 to 2.0 is necessary since support for validation of version 1.0
is not maintained.

(b) Multiple versions of the draft H-Anim v2.1 specification were prepared
and advanced but never finished the full process. As a result, any scenes
labeled H-Anim 2.1 are not necessarily consistent.

(c) In order to make further progress sensible, v2.2 has been proposed for
any current experimentation and proposed changes.

(d) Notes have been added to X3D Schema, DTD and Tooltips to indicate this
status.
< !-- Note that HAnim version 2.0 is approved, while versions 1.0/1.1 are
incompatible and version 2.2 is experimental. -->

This approach validates correct content while allowing further
experimentation.

b) Programmable shader component: Schema inheritance somewhat different from
specification

Specification reference:
http://www.web3d.org/documents/specifications/19775-1/V3.4/Part01/components
/shaders.html

Noted in Schema that concrete nodes are derived in non-standard way, because
of the need for 'mixed' content. Discussion of concerns re confusing node
names, e.g. ProgramShader and  ShaderProgram, a lack of examples and
possible platform dependencies with respect to the shader language. No
urgent action required other than adding missing 'metadata' fields.

Project wish  list: http://www.web3d.org/project-wish-list/ updated to
reflect this.

c) Mantis issue 692: Incorrect access type for 'knot' field in NurbsCurve
and NurbsCurve2D

See Nurbs component:
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components
/nurbs.html

Nodes affected:

NurbsCurve:
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components
/nurbs.html#NurbsCurve
<http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/component
s/nurbs.html%23NurbsCurve> 

NurbsCurve2D:
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components
/nurbs.html#NurbsCurve2D
<http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/component
s/nurbs.html%23NurbsCurve2D> 

NurbsOrientationInterpolator:
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components
/nurbs.html#NurbsOrientationInterpolator
<http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/component
s/nurbs.html%23NurbsOrientationInterpolator> 

NurbsPositionInterpolator:
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components
/nurbs.html#NurbsPositionInterpolator
<http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/component
s/nurbs.html%23NurbsPositionInterpolator> 

In first two nodes access type for 'knot' field is initializeOnly. In second
two nodes it is inputOutput. In Schema all four nodes have access type
initializeOnly.

Noted that for first two 'controlPoint' field has access type inputOutput
and can therefore change at run time. Changing 'controlPoint' at run time
could cause issues as relationship with 'order' and 'knot' fields has to be
maintained. See 27.2.3 Common geometry fields and correctness
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components
/nurbs.html#CommonGeometryFieldsAndCorrectness
<http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/component
s/nurbs.html%23CommonGeometryFieldsAndCorrectness> .

Extract from specification: "The number of knots shall be equal to the
number of control points plus the order of the curve."

It is certainly inconsistent to allow some fields (such as the different
'controlPoint' variations) to modify NURBS surface geometry and not others.

Note that changing NURBS nodes can provoke computational complexity at run
time. At least some ideas about avoiding such problems was one of the
original design considerations, when graphics processors were slower. (Don't
want to necessarily open the door to a computational denial of service
attack.) However, since the player itself is in charge of recomputation of
this parametric surface, and can modify the number polygons used to draw it,
the player can control that.

Most consistent approaches possible are either to prevent the author from
modifying NURBS parameters at run time, or else allow all of the parameters
to be modified at run time. These are dynamically rendered nodes by
definition, so preventing authors from further animating them is
inconsistent.

Recommended approach: change accessType from inputOnly to inputOutput for
all fields related to NURBS geometry definition.

This change has no impact on existing content and can be applied to all X3D
versions.

Guidance is also needed for authors that if they change more than one
parameter at a time, it is best to accomplish all modifications within a
single event-cascade timestep in order avoid computing
intermediate/incorrect/illegal NURBS geometry.

Project wish  list: http://www.web3d.org/project-wish-list/ updated to
reflect need for better Nurbs component support.

d) Auto generation of documents

General aims for XSLT work:

1)      Experimental auto generation of Classic VRML encoding clause 6
(complete and at testing phase).

2)      Use new auto generated VRML encoding document to improve Schema
consistency with specification (about 75% complete). Roy will circulate when
complete.

3)      Review auto generated XML encoding clause 6 and Java appendices,
verifying XSLT for each (latter required for 19777 specification submission
to ISO).

4)      Refactor XSLT files for better coding efficiency. For example
introduce Templates / functions to reduce code duplication.

5)      Develop new XSLT files for auto generation of clauses/annexes for
other language bindings.

6)      Produce auto generated table amalgamating all language bindings for
each node for easy cross-reference.

e) Schema review

Minor field corrections required for Schema and reported to mailing list
will be reviewed by Don and implemented as appropriate. Note: Most field
corrections do not affect validation of X3D files but are important for auto
generation of documentation.

Meeting closed 17:21 UTC.

Roy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20150527/759c30fa/attachment-0001.html>