<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Blaxxun Avatars use such a field, for example.</div>
<div> </div>
<div>You can use unconnected proto fields to carry instance related meta data of an proto instance.:</div>
<div> </div>
<div>
<div>$ cd Avatars_bscontact/</div>
<div>$ pwd<br/>
/c/christoph/software-projekte/ifra/013_SrrTrains/SrrFramework/simulrr/Avatars_bscontact</div>
<div>$ grep -r isAvatar<br/>
grintha-avatar.wrl: exposedField SFBool isAvatar TRUE<br/>
jane-avatar.wrl: exposedField SFBool isAvatar TRUE<br/>
joe-avatar.wrl: exposedField SFBool isAvatar TRUE<br/>
laura-avatar.wrl: exposedField SFBool isAvatar TRUE</div>
<div>$ ll<br/>
total 1021<br/>
-rw-r--r-- 1 x 197121 46379 May 26 2019 grintha.jpg<br/>
-rw-r--r-- 1 x 197121 312723 May 26 2019 grintha-avatar.wrl<br/>
-rw-r--r-- 1 x 197121 38735 May 26 2019 jane-avatar.jpg<br/>
-rw-r--r-- 1 x 197121 177503 May 26 2019 jane-avatar.wrl<br/>
-rw-r--r-- 1 x 197121 40764 May 26 2019 joe-avatar.jpg<br/>
-rw-r--r-- 1 x 197121 177501 May 26 2019 joe-avatar.wrl<br/>
-rw-r--r-- 1 x 197121 41880 May 26 2019 laura-avatar.jpg<br/>
-rw-r--r-- 1 x 197121 177502 May 26 2019 laura-avatar.wrl<br/>
-rw-r--r-- 1 x 197121 101 May 26 2019 license.txt<br/>
-rw-r--r-- 1 x 197121 9216 May 26 2019 Thumbs.db</div>
<div> </div>
</div>
<div>
<div>
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b> Freitag, 23. Oktober 2020 um 21:17 Uhr<br/>
<b>Von:</b> "Michalis Kamburelis" <michalis.kambi@gmail.com><br/>
<b>An:</b> "Andreas Plesch" <andreasplesch@gmail.com><br/>
<b>Cc:</b> "X3D Graphics public mailing list" <x3d-public@web3d.org><br/>
<b>Betreff:</b> Re: [x3d-public] unconnected proto fields</div>
<div name="quoted-content">I got my head stuck with the analogy """unused ProtoInstance field is<br/>
a similar situation to an unused routine parameter in normal<br/>
programming language""" :) That is why I wrote "parameter". Indeed<br/>
"field" seems a proper nomenclature when it comes to prototypes.<br/>
<br/>
In general I agree that the warning may be useful in some situations.<br/>
But I don't think this is the choice of the browser, to decide "this<br/>
is definitely invalid because the field is unused". The author may<br/>
choose to expose an (ignored) field in their prototype.<br/>
<br/>
In the use-case of "backward-compatibility", I can imagine either<br/>
decision making sense. Maybe the author doesn't have control over some<br/>
model using the prototype, so it is better to keep the old model<br/>
somewhat working (but with some field ignored) than to break it (by<br/>
removing the field from the prototype in another file)?<br/>
<br/>
Regards,<br/>
Michalis<br/>
<br/>
pt., 23 paź 2020 o 20:49 Andreas Plesch <andreasplesch@gmail.com> napisał(a):<br/>
><br/>
> I was not sure if connecting is actually required or not. Often being<br/>
> more strict seems to be the preferred option.<br/>
><br/>
> The underlying reason for being more strict about connecting is that<br/>
> x3dom needs to know the type of the field in case of node value fields<br/>
> when it registers the new node as an available x3d node.<br/>
><br/>
> Just like the signatures in the spec. spell out the type of node fields.<br/>
><br/>
> But what can be done is just using a default type of X3DNode for<br/>
> unconnected fields, and then otherwise ignoring the field.<br/>
><br/>
> > - maybe it was implemented one day, and it no longer works, but it<br/>
> > remains declared for 100% backward compatibility of the API? I.e.<br/>
> > author doesn't want to break existing EXTERNPROTO usage of the PROTO,<br/>
> > so it is better to leave an unused PROTO parameter.<br/>
><br/>
> I see that as a situation where it would be much better to have a<br/>
> warning or to fail to alert the user of the extern proto that the<br/>
> field that the instance is still using is actually not available<br/>
> anymore. Silence could lead to much soul searching and frustration.<br/>
><br/>
> Also, is it not more accurate to refer to the ProtoInstance fields as<br/>
> fields rather than parameters ?<br/>
><br/>
> cheers, -Andreas<br/>
><br/>
> On Fri, Oct 23, 2020 at 1:58 PM Michalis Kamburelis<br/>
> <michalis.kambi@gmail.com> wrote:<br/>
> ><br/>
> > I would say "Silently ignore" is what should be done. Specification<br/>
> > doesn't require that all prototype parameters are used.<br/>
> ><br/>
> > Some optional 'hint" from a browser ("the parameter xxx is unused")<br/>
> > may be helpful, but I would not call it a "warning". It may be a valid<br/>
> > situation. It's just like having a routine in any programming language<br/>
> > with an unused parameter: it is allowed, and sometimes it makes sense<br/>
> > (even when it's not a virtual method or a callback, where parameters<br/>
> > are forced to satisfy external requirements).<br/>
> ><br/>
> > Example when it makes sense:<br/>
> ><br/>
> > - maybe the author declares some prototype parameter, but has not<br/>
> > "implemented" it yet in the prototype? E.g. I have a PROTO "Car" where<br/>
> > I expose "SFColor color", but it's not yet implemented, and the<br/>
> > prototype always expands to a black car?<br/>
> ><br/>
> > - maybe it was implemented but is temporarily commented out?<br/>
> ><br/>
> > - maybe it was implemented one day, and it no longer works, but it<br/>
> > remains declared for 100% backward compatibility of the API? I.e.<br/>
> > author doesn't want to break existing EXTERNPROTO usage of the PROTO,<br/>
> > so it is better to leave an unused PROTO parameter.<br/>
> ><br/>
> > Regards,<br/>
> > Michalis<br/>
> ><br/>
> > pt., 23 paź 2020 o 19:45 Andreas Plesch <andreasplesch@gmail.com> napisał(a):<br/>
> > ><br/>
> > > A ProtoDeclaration may have fields in the interface definition which<br/>
> > > are then not connected to any fields or nodes in the ProtoBody.<br/>
> > ><br/>
> > > This is usually not the case since it does not seem to serve a<br/>
> > > purpose. Nonetheless authors may inadvertently define such unconnected<br/>
> > > fields in a ProtoInterface.<br/>
> > ><br/>
> > > Is there a requirement for such a connection ?<br/>
> > ><br/>
> > > Could there be a sensible use case for unconnected Proto fields ?<br/>
> > ><br/>
> > > How should a browser react to this?<br/>
> > ><br/>
> > > Silently ignore ? This is apparently the behaviour of many X3D<br/>
> > > browsers currently.<br/>
> > > Fail early ? To prevent any subsequent problems flowing from such an<br/>
> > > occurrence ? This is what x3dom currently does.<br/>
> > > A warning ? Seems reasonable unless there is a spec. requirement.<br/>
> > ><br/>
> > > -Andreas<br/>
> > ><br/>
> > > --<br/>
> > > Andreas Plesch<br/>
> > > Waltham, MA 02453<br/>
> > ><br/>
> > > _______________________________________________<br/>
> > > x3d-public mailing list<br/>
> > > x3d-public@web3d.org<br/>
> > > <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br/>
><br/>
><br/>
><br/>
> --<br/>
> Andreas Plesch<br/>
> Waltham, MA 02453<br/>
<br/>
_______________________________________________<br/>
x3d-public mailing list<br/>
x3d-public@web3d.org<br/>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a></div>
</div>
</div>
</div></div></body></html>