[x3d-public] Fw: ProtoInstance USE without name

[John Carlson]

Note that @name is not required in the ProtoInstance node because it is not
required in X3DUOM. If we want to require @name when @USE is absent, we
need to change X3DUOM first to require @name. If we also allow @USE along
with @name, that will really confuse the validator in my mind, but I
haven't thought about it long enough.

Suggestions?  I think I've been the only person talking about JSON in this
thread.

John

On Sat, Dec 5, 2020 at 5:52 PM John Carlson <yottzumm at gmail.com> wrote:

> 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/aa5f7a05/attachment-0001.html>