<div dir="auto">Yes, that was my question.<div dir="auto"><br></div><div dir="auto">The spec. does not have an opinion, and uses 'may' to indicate that ISing is optional.</div><div dir="auto"><br></div><div dir="auto">Use cases seem to be storage of values, silencing of potential errors and perhaps forwarding of events. More importantly, there are workflows which require such unconnected fields.</div><div dir="auto"><br></div><div dir="auto">Overall, I still feel that such fields signal a potential problem and browsers may react in some, nonblocking way.</div><div dir="auto"><br></div><div dir="auto">Andreas<br><br><div data-smartmail="gmail_signature" dir="auto">---on the phone---</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 24, 2020, 1:00 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Richard -- agree with everything you say. Prototype declaration must<br>
specify all fields fully (including defaults), and when instantiating<br>
prototypes -- you either specify a field value, or the default is<br>
used.<br>
<br>
But the question from Andreas that started this thread touches a<br>
little different problem, It's about "what if the prototype declares a<br>
field, but field remains unused in ProtoBody (implementation of the<br>
prototype)". Expressing this in X3D classic encoding, consider this:<br>
<br>
"""<br>
PROTO MyShape [<br>
  inputOutput SFNode geometry Sphere { }<br>
  inputOutput SFColor color 1 1 0<br>
] {<br>
  Shape {<br>
    appearance Appearance { material Material { } }<br>
    geometry IS geometry<br>
  }<br>
}<br>
"""<br>
<br>
The question is: what should the browser do about "color"? It is<br>
unused by the prototype implementation. In the above example, it is<br>
likely just a mistake of the author who forgot to write "diffuseColor<br>
IS color" (although higher in this thread I mention some cases when a<br>
field may be unused, but it's not a simple mistake). Should we just<br>
silently ignore this fact, or do something (like a warning or more).<br>
<br>
Regards,<br>
Michalis<br>
<br>
<br>
<br>
<br>
<br>
I think we discuss a bit different question wirth<br>
<br>
sob., 24 paź 2020 o 08:47 Richard F. Puk <<a href="mailto:puk@igraphics.com" target="_blank" rel="noreferrer">puk@igraphics.com</a>> napisał(a):<br>
><br>
> Hi, Michalis --<br>
><br>
> It seems to me that the correct answer should be that prototype declarations should be well-formed as are specified nodes. This means that all field in the prototype declaration should be fully specified. However, a prototype instance should behave like any other node so that an author can choose to use a field or not. If the field is not used by the prototype instance, the underlying "node" should use the default value for that field.<br>
><br>
>   -- Dick<br>
><br>
> /******************************************<br>
> | Richard F. Puk, Ph.D., President<br>
> | Intelligraphics Incorporated<br>
> | 7644 Cortina Court<br>
> | Carlsbad, CA  92009-8206<br>
> | Tel: +1-760-753-9027  Mobile:  +1-760-809-9027<br>
> | Email:  <a href="mailto:puk@igraphics.com" target="_blank" rel="noreferrer">puk@igraphics.com</a><br>
> \******************************************<br>
><br>
><br>
><br>
> -----Original Message-----<br>
> From: x3d-public [mailto:<a href="mailto:x3d-public-bounces@web3d.org" target="_blank" rel="noreferrer">x3d-public-bounces@web3d.org</a>] On Behalf Of Michalis Kamburelis<br>
> Sent: Friday, October 23, 2020 2:17 PM<br>
> To: Andreas Plesch<br>
> Cc: X3D Graphics public mailing list<br>
> Subject: Re: [x3d-public] unconnected proto fields<br>
><br>
> 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 <<a href="mailto:andreasplesch@gmail.com" target="_blank" rel="noreferrer">andreasplesch@gmail.com</a>> 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>
> > <<a href="mailto:michalis.kambi@gmail.com" target="_blank" rel="noreferrer">michalis.kambi@gmail.com</a>> 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 <<a href="mailto:andreasplesch@gmail.com" target="_blank" rel="noreferrer">andreasplesch@gmail.com</a>> 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>
> > > > <a href="mailto:x3d-public@web3d.org" target="_blank" rel="noreferrer">x3d-public@web3d.org</a><br>
> > > > <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer noreferrer" 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>
> <a href="mailto:x3d-public@web3d.org" target="_blank" rel="noreferrer">x3d-public@web3d.org</a><br>
> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
><br>
</blockquote></div>