[x3d-public] Fw: ProtoInstance USE without name

[Don Brutzman]

well whatever... regardless of agreement on relative merit, the only thing here that can actually change in software/validation is wording of warning provided by X3D Schematron.

X3D XML Schema and XML DOCTYPE cannot block this, we don't have any interdependency rules within those syntax validators.  (Similar kind of error that is beyond expressive power of those tools: simultaneous definition of DEF and USE within a single XML node definition.)

Assuming X3D4 completion and acceptance, in a few months when we get to revision of X3D XML Encoding 19776-1 we can consider special wording for ProtoInstance if it survives further scrutiny and consensus emerges on merit.  For today, as usual, X3D Schematron is following strict interpretation of specification:

* X3D XML encoding > 4 Concepts > 4.3.4 DEF and USE attribute syntax
   https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#DEFAndUSEAttributeSyntax

'Nodes containing a USE="someName" attribute can include no other attributes except containerField and class. Default values for other fields shall be ignored since field definitions in the original DEF node declaration have precedence.'

* X3D XML encoding > 4 Concepts > 4.3.10 ProtoInstance and fieldValue statement syntax
   https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#ProtoInstanceAndFieldValueStatement

(no special case regarding name and USE values found there)

For implementations loading a ProtoInstance USE node, acceptable behavior thus appears to include reporting if name field is mismatched, and also proceeding regardless of name value.

For the X3D Tooltips, the first two warnings are common to all X3D nodes.  The last/extra warning describes why the (current) strict interpretation of not including /name/ is acceptable, focusing author attention where it matters.

==================================
* X3D Tooltips, ProtoInstance, USE
   https://www.web3d.org/x3d/tooltips/X3dTooltips.html#ProtoInstance.USE

Warning: do NOT include any child nodes, a DEF attribute, or any other attribute values (except for containerField) when defining a USE attribute.
Warning: each USE value must match a corresponding DEF value that is defined earlier in the scene.
Warning: do not define a name field in a USE node, the correct name can already be found in the original ProtoInstance DEF node.
==================================

On 11/30/2020 7:47 PM, Andreas Plesch wrote:
> 
> ---on the phone---
> 
> On Mon, Nov 30, 2020, 10:17 PM Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu>> wrote:
> 
>     Thank you very much for error reports.
> 
>     On 11/29/2020 1:27 PM, Andreas Plesch wrote:
>      >
>      > Validator complaints:
>      >
>      > A: PigCompliant.x3d
>      >
>      > 7. Schematron check
>      >
>      > <ProtoInstance DEF="" USE="ThePig" name="Pig"/> includes unnecessary attribute name='Pig' which is not permitted for ProtoInstance USE node [/X3D/Scene/Transform/ProtoInstance, error]
>      >
>      > Well, the name attribute actually is permitted, at least in the spec., since ProtoInstance is not a x3d node by itself. Not sure why the validator claims it is not permitted. In addition, I think name should be allowed ( ideally required but not possible due to backward compatibility ).
> 
>     Hmmm.  Well since ProtoInstance acts like a node instance, I do treat it as such...
> 
> ProtoInstance by itself is meaningless. Protoinstance together with a name does instantiate a x3d node.

except when USE is present, then it is a reference (internally via whatever technique that a browser chooses) to the original DEF instantiation.

>     A statement like "having a name is optional" makes little sense, and even if not incorrect at the moment, change can easily lead to an error if any of the 4 DEF, USE or name values change, so the validator (X3D Schematron) doesn't allow it.
> 
> On the contrary, a concept of strictness may require to have a name attribute with USE to allow for redundancy in validation, in the same way regular X3D USE nodes need to match their DEF type.

Certainly possible but redundancy is typically not something that X3D requires.

>     Strictness is good.  Also follows an important design principle:
> 
>     * Wikipedia:  Don't repeat yourself (DRY)
>     https://en.wikipedia.org/wiki/Don't_repeat_yourself <https://en.wikipedia.org/wiki/Don't_repeat_yourself>

musical corollary: "Say something once, why say it again?"  Talking Heads

>      > B: PigNoName.x3d
>      >
>      > 7. Schematron check
>      >
>      > <Sound DEF=''/> minBack='40' maxBack='100' has minBack value greater than maxBack value [/X3D/Scene/ProtoDeclare/ProtoBody/Group/Sound, error] <Sound DEF=''/> minFront='40' maxFront='100' has minFront value greater than maxFront value [/X3D/Scene/ProtoDeclare/ProtoBody/Group/Sound, error]
>      >
>      > misfire of Validator, since 40 is not greater than 100. Perhaps alphabetical comparison rather than numerical in stylesheet.
> 
>     I suspect you are correct, since checking the existing logic looks OK.
> 
>     Now coercing XSLT typing of min/max front/back values to number(@minFront) before comparing...
> 
> ok. I can test again.
> 
>     Unit testing of TestSchematronDiagnostics.x3d cases all work so we should be OK now, update will deploy sometime.

the X3D Schematron correction was checked into version control immediately after successful testing.

will probably deploy update tonight, after applying X3DUrlObject refresh -> autoRefresh and add autoRefreshTimeLimit from Friday's teleconference.

>      > C: PigWorkaround.x3d
>      >
>      > <Script USE='ThePig'/> node type must match node type of original <ProtoInstance DEF='ThePig'/> [/X3D/Scene/Transform/Script, error]
>      >
>      >   Yes, pretty obvious but still accepted by quite a few browsers.
> 
>     Well obvious to scrupulous scrutinizing authors maybe but a really mysterious maddening source of error otherwise!
> 
> Actually, in this case it is the source of a workaround, an accidental solution to a problem.
> 
> all the best, Andreas
> 
>     Glad it worked.  8)
> 
>     [...]

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