[x3d-public] x3dom prototypes, extern proto

[Don Brutzman]

Checking ProtoDeclare and ExternProtoDeclare can be tricky, but I think it is correctly defined.

My understanding of the intent of that section was to prevent unexpected errors in the case of

a. ProtoDeclare defined,
b. ExternProtoDeclare and ProtoInstance example work and are deployed,
c. ProtoDeclare subsequently adds some additional fields or changes default field values,
d. ExternProtoDeclare and ProtoInstance example still work OK though new ProtoDeclare is retrieved at runtime.

Certainly the browser loading the original/updated ProtoDeclare must honor the behavior defined therein, including default values.

If the field interfaces within the ExternProtoDeclare (which only contain name, type, accessType and not default values) are different, that would be an error.

As above, if default values within the ProtoDeclare change, this has no impact on ExternProtoDeclare field definitions because they do not list default values.

When a ProtoInstance provides fieldValue initializations, they of course supersede whatever the default might be in the ProtoDeclare.

... so I think this all hangs together cleanly without contradiction or ambiguity.

Implementation-support notes:
- InstantReality handles cases well, although console warnings sometimes include false positives.
- X3D-Edit has a feature to check ExternProtoDeclare interfaces against ProtoDeclare interfaces.
- Utility methods for such checking would be a good feature to add to our Java, Python and JavaScript libraries.

Loading and checking for such consistency is typically not performed by any of our Quality Assurance (QA) tools since they tend to perform validations in an offline manner.  For X3DOM, I think this gap in testing coverage means that you should carefully check for consistency because if ProtoDeclare and ExternProtoDeclare differ then an incompatible interface is expected and model errors are likely.

Improvements always welcome.  Thanks for close scrutiny and thanks for tackling this super valuable capability for X3DOM.

On 6/23/2020 6:10 PM, Andreas Plesch wrote:
> ...
>> The next step would be to support the ExternProtoDeclare statement.
>> The main question I have is about the function of the additional field
>> statements under ExternProtoDeclare.
>>
>> - Do they replace ProtoInterface field statements ? (No.)
>> - Is the ProtoInterface element still required in the external file ? (Yes.)
>> - Are they listed just for convenience (for the author and the browser) ? (Yes?)
>> - Can they be ignored ? (Yes?)
> 
> I did find the clause "The names and types of the fields of the
> interface declaration shall be a subset of those defined in the
> implementation." in 4.4.5.2 EXTERNPROTO interface semantics. This
> means that an ExternProto can restrict access to fields by not listing
> them in its field elements. So they should not be ignored. On the
> other hand a browser which ignores them would still generate the same
> behaviour, minus warnings or errors in an ill-constructed scene when a
> ProtoInstance is trying to set non-accessible fields.
> 
> So I think as a first cut, it is ok to just load the external
> Protodeclaration and give it the name of the ExternProto and not doing
> much or anything with the field elements.
> 
>> Thanks for any insight,
>>
>> -Andreas
>>
>> --
>> Andreas Plesch
>> Waltham, MA 02453
> 
> --
> Andreas Plesch
> Waltham, MA 02453
> 
> _______________________________________________
> 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