[x3d-public] unconnected proto fields

Don Brutzman brutzman at nps.edu
Sun Oct 25 13:44:37 PDT 2020 

Yes and this is in keeping with our not being very directive on some issues in order to give browsers some leeway.  If we get very proscriptive, then that can get very burdensome to browsers and hurt performance or lead to undesirable side effects.

On 10/24/2020 12:57 PM, Richard F. Puk wrote:
> 
> Hi, Michalis --
> 
> If a field is specified in the prototype declaration but is not used in the prototype body, the field should behave like a noop (i.e., as if it was not specified).
> 
>    -- 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: Michalis Kamburelis [mailto:michalis.kambi at gmail.com]
> Sent: Saturday, October 24, 2020 12:00 PM
> To: Richard F. Puk
> Cc: Andreas Plesch; X3D Graphics public mailing list
> Subject: Re: [x3d-public] unconnected proto fields
> 
> 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
>>
> 
> 
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> 

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman

More information about the x3d-public mailing list