[x3d-public] unconnected proto fields

Sat Oct 24 12:18:55 PDT 2020

Yes, that was my question.

The spec. does not have an opinion, and uses 'may' to indicate that ISing
is optional.

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.

Overall, I still feel that such fields signal a potential problem and
browsers may react in some, nonblocking way.

Andreas

---on the phone---

On Sat, Oct 24, 2020, 1:00 PM Michalis Kamburelis <michalis.kambi at gmail.com>
wrote:

> Richard -- agree with everything you say. Prototype declaration must
> specify all fields fully (including defaults), and when instantiating
> prototypes -- you either specify a field value, or the default is
> used.
>
> But the question from Andreas that started this thread touches a
> little different problem, It's about "what if the prototype declares a
> field, but field remains unused in ProtoBody (implementation of the
> prototype)". Expressing this in X3D classic encoding, consider this:
>
> """
> PROTO MyShape [
>   inputOutput SFNode geometry Sphere { }
>   inputOutput SFColor color 1 1 0
> ] {
>   Shape {
>     appearance Appearance { material Material { } }
>     geometry IS geometry
>   }
> }
> """
>
> The question is: what should the browser do about "color"? It is
> unused by the prototype implementation. In the above example, it is
> likely just a mistake of the author who forgot to write "diffuseColor
> IS color" (although higher in this thread I mention some cases when a
> field may be unused, but it's not a simple mistake). Should we just
> silently ignore this fact, or do something (like a warning or more).
>
> Regards,
> Michalis
>
>
>
>
>
> I think we discuss a bit different question wirth
>
> sob., 24 paź 2020 o 08:47 Richard F. Puk <puk at igraphics.com> napisał(a):
> >
> > Hi, Michalis --
> >
> > 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.
> >
> >   -- Dick
> >
> > /******************************************
> > | Richard F. Puk, Ph.D., President
> > | Intelligraphics Incorporated
> > | 7644 Cortina Court
> > | Carlsbad, CA  92009-8206
> > | Tel: +1-760-753-9027  Mobile:  +1-760-809-9027
> > | Email:  puk at igraphics.com
> > \******************************************
> >
> >
> >
> > -----Original Message-----
> > From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of
> Michalis Kamburelis
> > Sent: Friday, October 23, 2020 2:17 PM
> > To: Andreas Plesch
> > Cc: X3D Graphics public mailing list
> > Subject: Re: [x3d-public] unconnected proto fields
> >
> > I got my head stuck with the analogy """unused ProtoInstance field is
> > a similar situation to an unused routine parameter in normal
> > programming language""" :) That is why I wrote "parameter". Indeed
> > "field" seems a proper nomenclature when it comes to prototypes.
> >
> > In general I agree that the warning may be useful in some situations.
> > But I don't think this is the choice of the browser, to decide "this
> > is definitely invalid because the field is unused". The author may
> > choose to expose an (ignored) field in their prototype.
> >
> > In the use-case of "backward-compatibility", I can imagine either
> > decision making sense. Maybe the author doesn't have control over some
> > model using the prototype, so it is better to keep the old model
> > somewhat working (but with some field ignored) than to break it (by
> > removing the field from the prototype in another file)?
> >
> > Regards,
> > Michalis
> >
> > pt., 23 paź 2020 o 20:49 Andreas Plesch <andreasplesch at gmail.com>
> napisał(a):
> > >
> > > I was not sure if connecting is actually required or not. Often being
> > > more strict seems to be the preferred option.
> > >
> > > The underlying reason for being more strict about connecting is that
> > > x3dom needs to know the type of the field in case of node value fields
> > > when it registers the new node as an available x3d node.
> > >
> > > Just like the signatures in the spec. spell out the type of node
> fields.
> > >
> > > But what can be done is just using a default type of X3DNode for
> > > unconnected fields, and then otherwise ignoring the field.
> > >
> > > > - maybe it was implemented one day, and it no longer works, but it
> > > > remains declared for 100% backward compatibility of the API? I.e.
> > > > author doesn't want to break existing EXTERNPROTO usage of the PROTO,
> > > > so it is better to leave an unused PROTO parameter.
> > >
> > > I see that as a situation where it would be much better to have a
> > > warning or to fail to alert the user of the extern proto that the
> > > field that the instance is still using is actually not available
> > > anymore. Silence could lead to much soul searching and frustration.
> > >
> > > Also, is it not more accurate to refer to the ProtoInstance fields as
> > > fields rather than parameters ?
> > >
> > > cheers, -Andreas
> > >
> > > On Fri, Oct 23, 2020 at 1:58 PM Michalis Kamburelis
> > > <michalis.kambi at gmail.com> wrote:
> > > >
> > > > I would say "Silently ignore" is what should be done. Specification
> > > > doesn't require that all prototype parameters are used.
> > > >
> > > > Some optional 'hint" from a browser ("the parameter xxx is unused")
> > > > may be helpful, but I would not call it a "warning". It may be a
> valid
> > > > situation. It's just like having a routine in any programming
> language
> > > > with an unused parameter: it is allowed, and sometimes it makes sense
> > > > (even when it's not a virtual method or a callback, where parameters
> > > > are forced to satisfy external requirements).
> > > >
> > > > Example when it makes sense:
> > > >
> > > > - maybe the author declares some prototype parameter, but has not
> > > > "implemented" it yet in the prototype? E.g. I have a PROTO "Car"
> where
> > > > I expose "SFColor color", but it's not yet implemented, and the
> > > > prototype always expands to a black car?
> > > >
> > > > - maybe it was implemented but is temporarily commented out?
> > > >
> > > > - maybe it was implemented one day, and it no longer works, but it
> > > > remains declared for 100% backward compatibility of the API? I.e.
> > > > author doesn't want to break existing EXTERNPROTO usage of the PROTO,
> > > > so it is better to leave an unused PROTO parameter.
> > > >
> > > > Regards,
> > > > Michalis
> > > >
> > > > pt., 23 paź 2020 o 19:45 Andreas Plesch <andreasplesch at gmail.com>
> napisał(a):
> > > > >
> > > > > A ProtoDeclaration may have fields in the interface definition
> which
> > > > > are then not connected to any fields or nodes in the ProtoBody.
> > > > >
> > > > > This is usually not the case since it does not seem to serve a
> > > > > purpose. Nonetheless authors may inadvertently define such
> unconnected
> > > > > fields in a ProtoInterface.
> > > > >
> > > > > Is there a requirement for such a connection ?
> > > > >
> > > > > Could there be a sensible use case for unconnected Proto fields ?
> > > > >
> > > > > How should a browser react to this?
> > > > >
> > > > > Silently ignore ? This is apparently the behaviour of many X3D
> > > > > browsers currently.
> > > > > Fail early ? To prevent any subsequent problems flowing from such
> an
> > > > > occurrence ? This is what x3dom currently does.
> > > > > A warning ? Seems reasonable unless there is a spec. requirement.
> > > > >
> > > > > -Andreas
> > > > >
> > > > > --
> > > > > Andreas Plesch
> > > > > Waltham, MA 02453
> > > > >
> > > > > _______________________________________________
> > > > > x3d-public mailing list
> > > > > x3d-public at web3d.org
> > > > > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> > >
> > >
> > >
> > > --
> > > Andreas Plesch
> > > Waltham, MA 02453
> >
> > _______________________________________________
> > x3d-public mailing list
> > x3d-public at web3d.org
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20201024/88c4c5da/attachment.html>