<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Date: Sun, 29 Nov 2020 10:45:58 -0800<br>
From: Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>><br>
To: John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>><br>
Cc: "<a href="mailto:vmarchetti@kshell.com" target="_blank">vmarchetti@kshell.com</a>" <<a href="mailto:vmarchetti@kshell.com" target="_blank">vmarchetti@kshell.com</a>>, X3D-Public<br>
        <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
Subject: Re: [x3d-public] X3D4 finalization endgame: Field naming<br>
        reconciliation as synonyms<br><br>
Clearly duplicated definition of synonym field values is a model error that validation-oriented tools will notice and report.<br></blockquote><div><br></div><div>This applies to the initialization phase of field values. Does it also apply to dynamic changes, via ROUTEs or Scripts of field values ? Such dynamic changes are hard to detect in validation.</div><div><br></div><div>I think what this means is that the idea is that a Scene can only use one of the field synonyms for a given node throughout. In turn, such a requirement would need to be stated in the spec., otherwise authors will mix and match at will.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
As carefully phrased in prior response and in existing specification, when an X3D model is erroneous then behavior is undefined.<br>
<br>
So there is no need to define expected response (first second alphabetical neither nor) and no additional burden on implementers to cope with duplicates.  The implementation can ignore silently, protest once, protest twice, halt and catch fire, whatever.  8)<br></blockquote><div><br></div><div>Unfortunately, I think there is still a significant burden on implementers because browsers still have to deal with dynamic changes to fields. It will be probably necessary to add an intermediate layer which deals with synonyms and resolves them to the single, internal field. Other implementers may have a different view.</div><div><br></div><div>-Andreas</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On 11/29/2020 10:10 AM, John Carlson wrote:<br>
> <br>
> Fixed editing?mistake.<br>
> <br>
> On Sun, Nov 29, 2020 at 12:09 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a> <mailto:<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>>> wrote:<br>
> <br>
>     I think it's more critical when both oldName and newName exist in XML or VRML (in JSON, last takes precedence, I think). Which?value do you store last when both the new and old attributes are specified in XML?? ?Some kind of ordering?will exist?in the tools processing the XML, but without a standard, there may be alternate implementations.<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>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<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>
<br>
End of x3d-public Digest, Vol 140, Issue 89<br>
*******************************************<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Andreas Plesch<br>Waltham, MA 02453</div></div></div></div>