<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1739740681;
mso-list-type:hybrid;
mso-list-template-ids:-1687650764 134807569 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>Minutes for Schema/DTD Review meeting Monday 25<sup>th</sup> May 2015 15:00 UTC (08:00 PDT, 16:00 BST)<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Attendees: Don Brutzman, Roy Walmsley<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>a) Mantis issue 691: <u>Illegal default issues for fields in HAnim component<o:p></o:p></u></b></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><a name=bugnotes>The relevant specification sections for field ‘version’ follow. Both list "" as default value.<br><br>X3D 19775-1 26.3.2 HAnimHumanoid </a><a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/hanim.html#HAnimHumanoid">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/hanim.html#HAnimHumanoid</a><br><br>H-Anim 19774 6.2 Humanoid <a href="http://www.web3d.org/documents/specifications/19774/V1.0/HAnim/ObjectInterfaces.html#Humanoid">http://www.web3d.org/documents/specifications/19774/V1.0/HAnim/ObjectInterfaces.html#Humanoid</a><br><br>... then later in the section says.<br>==============<br>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”.<br>==============<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The historical confusion of the ‘version’ numbers was explained, and the need for clearer documentation noted, as follows.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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’: <a href="http://x3dgraphics.com/slidesets/X3dForAdvancedModeling/HumanoidAnimation.pdf">http://x3dgraphics.com/slidesets/X3dForAdvancedModeling/HumanoidAnimation.pdf</a><br><br>Problems:<br>(a) Past humanoid version 1.0 was not compatible with the 2.0 X3D Schema/DTD and<br>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.<br><br>(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.<br><br>(c) In order to make further progress sensible, v2.2 has been proposed for any current experimentation and proposed changes.<br><br>(d) Notes have been added to X3D Schema, DTD and Tooltips to indicate this status.<br>< !-- Note that HAnim version 2.0 is approved, while versions 1.0/1.1 are incompatible and version 2.2 is experimental. --><br><br>This approach validates correct content while allowing further experimentation.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>b) <b>Programmable shader component: <u>Schema inheritance somewhat different from specification</u></b><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Specification reference: <span style='color:black;background:white;mso-highlight:white'><a href="http://www.web3d.org/documents/specifications/19775-1/V3.4/Part01/components/shaders.html">http://www.web3d.org/documents/specifications/19775-1/V3.4/Part01/components/shaders.html</a></span><span style='color:black'><o:p></o:p></span></p><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:black'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:black'>Project wish list: <a href="http://www.web3d.org/project-wish-list/">http://www.web3d.org/project-wish-list/</a> updated to reflect this.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='color:black'>c) Mantis issue 692: </span><u>Incorrect access type for 'knot' field in NurbsCurve and NurbsCurve2D<o:p></o:p></u></b></p><p class=MsoNormal><b><u><o:p><span style='text-decoration:none'> </span></o:p></u></b></p><p class=MsoNormal>See Nurbs component: <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/nurbs.html">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/nurbs.html</a><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Nodes affected:<o:p></o:p></p><p class=MsoNormal>NurbsCurve: <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/nurbs.html%23NurbsCurve">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/nurbs.html#NurbsCurve</a><o:p></o:p></p><p class=MsoNormal>NurbsCurve2D: <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/nurbs.html%23NurbsCurve2D">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/nurbs.html#NurbsCurve2D</a><o:p></o:p></p><p class=MsoNormal>NurbsOrientationInterpolator: <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/nurbs.html%23NurbsOrientationInterpolator">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/nurbs.html#NurbsOrientationInterpolator</a><o:p></o:p></p><p class=MsoNormal>NurbsPositionInterpolator: <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/nurbs.html%23NurbsPositionInterpolator">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/nurbs.html#NurbsPositionInterpolator</a><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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 <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/nurbs.html%23CommonGeometryFieldsAndCorrectness">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/nurbs.html#CommonGeometryFieldsAndCorrectness</a>.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Extract from specification: “The number of knots shall be equal to the number of control points plus the order of the curve.”<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>It is certainly inconsistent to allow some fields (such as the different ‘controlPoint’ variations) to modify NURBS surface geometry and not others.<br><br>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.<br><br>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.<br><br>Recommended approach: change accessType from inputOnly to inputOutput for all fields related to NURBS geometry definition.<br><br>This change has no impact on existing content and can be applied to all X3D versions.<br><br>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='color:black'>Project wish list: <a href="http://www.web3d.org/project-wish-list/">http://www.web3d.org/project-wish-list/</a> updated to reflect need for better Nurbs component support.<o:p></o:p></span></p><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='color:black'>d) <u>Auto generation of documents<o:p></o:p></u></span></b></p><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:black'>General aims for XSLT work:<o:p></o:p></span></p><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='color:black'><span style='mso-list:Ignore'>1)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:black'>Experimental auto generation of Classic VRML encoding clause 6 (complete and at testing phase).<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='color:black'><span style='mso-list:Ignore'>2)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:black'>Use new auto generated VRML encoding document to improve Schema consistency with specification (about 75% complete). Roy will circulate when complete.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='color:black'><span style='mso-list:Ignore'>3)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:black'>Review auto generated XML encoding clause 6 and Java appendices, verifying XSLT for each (latter required for 19777 specification submission to ISO).<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='color:black'><span style='mso-list:Ignore'>4)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:black'>Refactor XSLT files for better coding efficiency. For example introduce Templates / functions to reduce code duplication.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='color:black'><span style='mso-list:Ignore'>5)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:black'>Develop new XSLT files for auto generation of clauses/annexes for other language bindings.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='color:black'><span style='mso-list:Ignore'>6)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:black'>Produce auto generated table amalgamating all language bindings for each node for easy cross-reference.<o:p></o:p></span></p><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='color:black'>e) <u>Schema review<o:p></o:p></u></span></b></p><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:black'>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.<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Meeting closed 17:21 UTC.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Roy<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>