[x3d-public] Fw: ProtoInstance USE without name

[Andreas Plesch]

---on the phone---

On Sat, Dec 5, 2020, 3:37 PM Don Brutzman <brutzman at nps.edu> wrote:

> 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.'
>

'Nodes' seems to refer to X3D nodes but may be intended to refer to XML
nodes. To avoid ambiguity, consider specifying 'XML elements' instead. I
think strictly speaking attributes are also nodes in XML

With such a change ProtoInstance would fall under that requirement.



> * 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.
>

The big exception is USE in the XML encoding. To avoid redundancy a design
like

<USE name='DEFname' />

would have been necessary but was not preferred.

>
> >     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
>

Database design also comes to mind.


> >      > 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.
>

will follow-up after testing.

Cheers, Andreas


> >      > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20201205/c1bb67da/attachment.html>