<div dir="ltr">What I am concerned with about @USE and @name is that I perhaps am adding yet another subschema for each node with @name field schema.  That means adding around 50% more subschemas.   Additional schemas means slower processing etc. I might prefer to go back to the original style, where all fields are in the same subschema.  It certainly was easier for the user, albeit incorrect.  We would be no worse off than XML schema, and we still have the opportunity to start with XML so we can go through the schematron.   Discussions of possible JSON schematron or validating with X3DJSAIL or x3dpsail welcome (I'm not ready to discuss es6x3d right now).<div><br></div><div><div><br></div><div>John</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 6, 2020 at 9:05 AM 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"><div dir="ltr">Please provide test cases.  I think we will have these 3 subschemas (choose one):<div><br></div><div>@USE required, (no other fields allowed)<br></div><div>@name required && @USE required (no other fields allowed)<br></div><div>@name required @USE not allowed (other fields allowed)</div><div>Other options not allowed (must have @USE or @name).  Generally, we will match just one of the subschemas. @containerField is not in JSON.</div><div><br></div><div>Does this apply for ProtoInstance and all other nodes with @name field, or just ProtoInstance?</div><div><br>Let's work through this logically.</div><div><br></div><div>I'm assuming at some point you will be creating a stylesheet for generating schema, or perhaps preferably, validation code.</div><div><br>I think I'm going to wait for draft 8 until Ajv catches up, ns.  I think Ajv 7 may still be in beta.  There's a promising JavaScript validator that might be used instead, but it looks like it may require major changes to code, ns.</div><div><br></div><div>Thanks,</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 9:56 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 4:00 PM, John Carlson wrote:<br>
> <br>
> If anyone is using the generated X3D Schema (4.0), let me know.<br>
<br>
Yes I certainly remain interested John but have a lot of other work on X3D4 that must get resolved first.<br>
<br>
In general, as we succeeded before, I expect that when we add JSON Schema draft 8 validation to the existing X3D JSON encoding, it will remain a nearly exact match with X3D XML encoding where node/field (element/attribute) data delimiters and some string escaping are the only differences.<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></div>
</blockquote></div>