Consider defaultgeomprop when validating an input.

[kwokcb]

An input without a value or connection but a defaultgeomprop should not be considered to be invalid.

• Add in logic to avoid these validation errors from occurring.
• Testing with node editor shows that validation ordering logic is incorrect and that validation occurs with
  any definitions loading in. Do a small patch for that. Viewer is correct.

Example created in node editor which is considered invalid and would fail unit tests.

<?xml version="1.0"?>
<materialx version="1.38">
  <translucent_bsdf name="translucent_bsdf" type="BSDF" xpos="10.521739" ypos="-1.534483" >
    <input name="normal" type="vector3" />
  </translucent_bsdf>
  <surface name="surface" type="surfaceshader" xpos="13.188406" ypos="-1.810345">
    <input name="bsdf" type="BSDF" nodename="translucent_bsdf" />
  </surface>
  <surfacematerial name="surfacematerial" type="material" xpos="15.188406" ypos="-2.068965">
    <input name="surfaceshader" type="surfaceshader" nodename="surface" />
  </surfacematerial>
</materialx>

[jstone-lucasfilm]

@kwokcb In your example above, wouldn't we simply want the graph editor to omit the normal input of the translucent_bsdf node? Since it's not binding any new data, it seems like it's a bug that the editor writes this out, and we should address the warning message on that side instead.

[kwokcb]

I just happen to use the editor but it's pretty easy to add an input to an instance and get this warning.
Someone could have this input and then connect to it afterwards as well without the need for a warning.

[jstone-lucasfilm]

Isn't that the purpose of this validate warning, though, to let the user know that they have added an input that has no effect on the interpretation of the document?

I'm not seeing how the presence of a defaultgeomprop on the underlying NodeDef makes this construction any more valid than if no defaultgeomprop was present.

My sense is that we should be consistent and emit the warning in all invalid cases, rather than omitting the warning in invalid cases that represent particularly easy mistakes for the exporting application to make.

[jstone-lucasfilm]

I'll close this pull request for now, since there's room for debate as to whether this would be an improvement to the validation rules.