<div><br></div><div dir="auto">One thing I am fearful of for our users is that they use multiple synonyms within a synonym group, and expect that different field values won’t get overwritten.</div><div dir="auto"><br></div><div dir="auto">John</div><div dir="auto"><br></div><div dir="auto">On Sun, Nov 29, 2020 at 9:52 AM <a href="mailto:vmarchetti@kshell.com">vmarchetti@kshell.com</a> <<a href="http://vmarchett.com">vmarchett.com</a>> wrote:<div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Answering the question as posed:<br>
<br>
> Feedback choices for determining consensus:<br>
> a. I can    work with the proposed change to refactor and normalize certain field names as synonyms in X3D4.<br>
> (b). I cannot work with the proposed change to refactor and normalize certain field names as synonyms in X3D4, because ___.<br>
<br>
I will answer a, I can work with the proposed change. <br>
<br>
I will recommend against the addition of the concept of synonyms into the v4 spec. The proposed change, at least in case of the CADFace node, is quite easy to describe: the field that in v 3.3 is called 'shape' will be called 'children' in v 4, with otherwise the same meaning and restrictions applied to the value of this field. It is probably a very simple change to make in in implementation code. Adding a new concept of synonym, alias, or dialect saddles our browser implementers with a new implementation challenge.<br>
<br>
We should not hide the fact that changing the name of a field breaks backward compatibility, which I define as requiring that a X3D file valid under version 3.3 does not become invalid when when the only change is that the version specifier in the header is changed to 4.0 . Breaking backward compatibility defined in this strict way is not a capital offense, and probably has already occurred in the history of the X3D specification.<br>
<br>
However, breaking backward compatibility does have implications for both authors and implementors. Besides deciding when to roll out X3D content that uses new capabilities such as physically based rendering, they also need to decide when to change the names of the fields in what is otherwise valid X3D 3.3 content. Speaking as a content producer, my decision will be to stop using the CADGeometry component until explicit demand from paying clients requires me to make the change.<br>
<br>
Vince Marchetti<br>
<br>
<br>
<br>
<br>
> On Nov 28, 2020, at 3:13 PM, Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br>
> <br>
> Summary: further description of tradeoffs and a request for determining consensus follows.<br>
> <br>
> On 11/20/2020 8:56 AM, Don Brutzman wrote:<br>
>> Meeting minutes for Friday November 20, 0800-0900 Pacific.<br>
>> [...]<br>
>> 3. X3D4 finalization<br>
>> a. Prose in Lighting and Shape components<br>
>> b. Lighting values greater than 1, should we explain?<br>
>> c. outlining then drafting Annex M, HTML5 Integration Guidelines<br>
>> d. XSLT cleanup to remove all editorial markup and create pristine votable CD text<br>
>> and...<br>
>> e. Field naming reconciliation for similar/identical fields with different names<br>
>>    <a href="https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#fieldNameChanges" rel="noreferrer" target="_blank">https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#fieldNameChanges</a><br>
>> Tradeoff: whether streamlining and consistency outweighs backwards symmetry.  This is not a functional compatibility issue, rather where is the burden placed.  Some work is always needed to create an X3D4 player, some understanding is always needed for authors who want to use X3D3 models with X3D4.<br>
>> Perhaps related: do we need to create a set of guidelines for X3D4 support of X3D3 loading (or X3D3 browser upgrade to X3D4 support)?  We are hoping this will be minimalist or nonexistent (for example, X3D3 models cannot load X3D4 models).<br>
>> Good topic for mailing list - any opinions out there?<br>
> Further insight: the essence of this issue is whether we ask browser implementers to support field flexibility (a one-time effort) or else ask HTML5/X3D4 authors to remember idiosyncratic differences in naming that, if not honored, typically fail silently (within the DOM).<br>
> <br>
> This issue decides how to shift a necessary burden one way or another: either additional software effort to support X3D4, versus simplified authoring of future content.<br>
> <br>
> Dick had an excellent suggestion that we might formalize the relationships but declaring that original/revised field names are "synonyms" in the X3D4 specification.  Seems do-able, and also ensures that updated specification-compliant software avoids any compatibility problems.  This avoids any effect on existing X3D3 models or software.<br>
> <br>
> Based on implementation experience, I think that synonyms are implementable without much difficulty in XML schemas/DTDs, X3DJSAIL, X3DPSAIL, X3D Validator, and a number of other converters that we maintain in Web3D open source.  I can work with the proposed change.  So the additional level of one-time effort when upgrading is not expected to be great in other emerging X3D4 tools.<br>
> <br>
> Emphasis on diagnostics, converters and validation, in combination with formal "synonym" status, will likely minimize any backwards compatibility issues.  The number of affected scenes in the X3D Example Archives is relatively small (perhaps dozens, definitely not hundreds, sample space 4000).  These are all diverse edge cases that can be regularized effectively, avoiding mysterious content failures in the future.  No functional changes to X3D scene graph rendering are involved.<br>
> <br>
> If indeed "content is king" then favoring authorability over a one-time software refinement seems like a clear priority.<br>
> <br>
> I continue to request and recommend this change because now is the right time for us to execute, as part of major update to X3D4.<br>
> <br>
> To ensure all parties are heard from, I hereby request determination of X3D working group consensus.<br>
> <br>
> Feedback choices for determining consensus:<br>
> a. I can    work with the proposed change to refactor and normalize certain field names as synonyms in X3D4.<br>
> a. I cannot work with the proposed change to refactor and normalize certain field names as synonyms in X3D4, because ___.<br>
> <br>
> Please submit all responses and rationales prior to next Friday's X3D Working Group meeting.  Thanks for considering the tradeoffs<br>
> <br>
> all the best, Don<br>
> -- <br>
> Don Brutzman  Naval Postgraduate School, Code USW/Br       <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149<br>
> X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzman</a><br>
> <br>
> _______________________________________________<br>
> x3d-public mailing list<br>
> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
<br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div></div>