<div dir="ltr">Sorry for all the duplication. And currently JSON schema does not come into play with either X3DOM or X_ITE. So the only apps affected are the X3DJSONLD website, which includes the JSON validator, which you can try out here: <a href="http://coderextreme.net/X3DJSONLD/src/main/html/validator.html">http://coderextreme.net/X3DJSONLD/src/main/html/validator.html</a><div><br></div><div>Good luck with X3D JSON!</div><div><br></div><div>If anyone is using the generated X3D Schema (4.0), let me know.</div><div><br></div><div>John</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Dec 5, 2020 at 5:52 PM John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>If this is all too onerous, I will merely pass the validation task onto the browser (sorry!).</div><div><br></div><div>John</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Dec 5, 2020 at 5:33 PM Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 12/5/2020 2:41 PM, Andreas Plesch wrote:<br>
> [...] <br>
> 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:<br>
> <br>
> * X3D XML encoding > 4 Concepts > 4.3.4 DEF and USE attribute syntax<br>
> <a href="https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#DEFAndUSEAttributeSyntax" rel="noreferrer" target="_blank">https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#DEFAndUSEAttributeSyntax</a> <<a href="https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#DEFAndUSEAttributeSyntax" rel="noreferrer" target="_blank">https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#DEFAndUSEAttributeSyntax</a>><br>
> <br>
> '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.'<br>
> <br>
> '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<br>
> <br>
> With such a change ProtoInstance would fall under that requirement.<br>
<br>
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.<br>
<br>
So the quoted 'Nodes' above is X3D node and also XML element.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
all the best, Don<br>
-- <br>
Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<br>
X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzman</a><br>
</blockquote></div>
</blockquote></div>