[x3d-public] Fw: ProtoInstance USE without name

[John Carlson]

Yes, and the JSON schema will not allow @containerField (but currently
allows @class along with other nodes). If @USE is present, @name is not
allowed. I do not think that X3dToJson.xslt needs to be changed with
regards to this, but DOM2JSONSerializer.js may need to delete @name when
converting a @USE'd ProtoInstance to JSON.

The main concern with allowing @name is the combinatorics involved with
validating. Yes, we can generate a huge schema, but it will be doubly hard
to include all the various possible subschemas.  Currently we have 2.  One
for @USE present (leaving out @name), and one for @USE absent (including
@name, but not requiring it).  If this should be modified to agree with the
JSON schema or architecture, let me know.   What I'm worried about is
requiring @name when @USE is absent. I don't think I've covered that case
yet.

If this is all too onerous, I will merely pass the validation task onto the
browser (sorry!).

John

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

> On 12/5/2020 2:41 PM, Andreas Plesch wrote:
> > [...]
> >     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
> <
> 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.
>
> In general: 19775-1 X3D Architecture refers to X3D nodes, while 19776-2
> X3D XML encoding refers to XML elements representing those same X3D nodes.
>
> So the quoted 'Nodes' above is X3D node and also XML element.
>
> I don't think we want the abstract Architecture to say anything about XML,
> but to continue to strive for an Architecture that has fully representable
> functionality in each of the subsidiary file encoding (19776-*) and
> programming language bindings (19777-*) standards.
>
> This all requires careful phrasing!  In case anyone isn't wary yet,
> XML-speak (and DOM) often refers to XML elements as document nodes, as well.
>
> It is a little bit of a chore when programming a parser with ProtoInstance
> USE support to look up the name of the original DEF ProtoInstance, but
> knowing that consistency is correct in a scene is certainly helpful.
>
> And so, still thinking our current state of affairs to have XML models
> with a ProtoInstance USE not require a name (while clearly erroneous if an
> included name mismatches) seems OK and provides round-trippable correct
> results.  This pattern also played out satisfactorily in the JSON encoding,
> Java X3DJSAIL and Python x3d.py without mishap.
>
> 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/50c5017e/attachment.html>