<div dir="auto">What I would recommend is a .bat, powershell or shell script that takes several file names as arguments, xml and json encoded (or other), and validates the. This is probably done?? It takes a lot of typing getting the class name typed out.</div><div dir="auto"><br></div><div dir="auto">This is good for when you want to validate a bunch of files in a pipeline. I use pipelines a lot!</div><div dir="auto"><br></div><div dir="auto">Since I have a use for this, I will try to work something up.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto"><br></div><div dir="auto">John</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 25, 2023 at 12:51 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-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="auto">Here are the CommandLine instructions:</div><div dir="auto"><br></div><div dir="auto"><div><a href="https://www.web3d.org/specifications/java/X3DJSAIL.html" target="_blank">https://www.web3d.org/specifications/java/X3DJSAIL.html</a></div></div><div dir="auto"><br></div><div dir="auto">John</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 25, 2023 at 12:48 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="auto">In total agreement, great effort on X3DJSAIL’s validation features. Perhaps there is an instruction on how to validate XML encoded files with X3DJSAIL? Can X3DJSAIL be integrated into other projects like X3dValidator, X3D-Edit, and beyond? I’m pretty sure we don’t want to use X3DJSAIL on large batches? Onesies are probably fine.</div><div dir="auto"><br></div><div dir="auto">I’m talking about the possibility of validation beyond what schema and x3duom can provide, stuff in the x3djsail generator stylesheet.</div><div dir="auto"><br></div><div dir="auto">Plus!!! A good way to run from the command-line or ant!</div><div dir="auto"><br></div><div dir="auto">I recall a -validate flag to CommanLine.java</div><div dir="auto"><br></div><div dir="auto">I’ll check out the X3DJSAIL page.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto"><br></div><div dir="auto">John</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 25, 2023 at 9:47 AM Brutzman, Donald (Don) (CIV) <<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-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Belated response, apologies for delay.<br>
<br>
Thanks for excellent analysis Vince.<br>
<br>
I think that when we begin updating the ClassicVRML encoding to match X3D<br>
4.0, that will be the time to update the ClassicVRML grammar. Hopefully<br>
this fall.<br>
<br>
Contributions (such as formal grammar refinements) are always welcome, we<br>
capture them from the mailing list and record them in our deliberate issue<br>
list in the Mantis tracking system.<br>
<br>
Finally am happy to emphasize that there is a concrete way to determine<br>
whether each file encoding (XML, ClassicVRML, JSON, EXI, Turtle) and<br>
programming-language binding (JavaScript, Java, Python, C, C++, C#) is<br>
consistently applying the common guidance in the X3D Architecture:<br>
round-trip conversions are possible in each direction that preserve all of<br>
the geometry and animation content in an author's X3D model. Success<br>
typically includes validation as a way to confirm such correctness.<br>
Successful loading by other tools is another measure of maturity,<br>
correctness, and success.<br>
<br>
So there is plenty of implementation effort still possible, improving<br>
quality assurance (QA). Every bit of it incremental and often adapting<br>
capabilities that we already know how to perform well.<br>
<br>
Biggest beneficiaries are authors and users, on the Web or offline (or<br>
perhaps someday in the Metaverse), who get to consistently utilize<br>
interactive X3D models anywhere.<br>
<br>
Have fun with X3D! 8)<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="https://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">https://faculty.nps.edu/brutzman</a><br>
<br>
-----Original Message-----<br>
From: Vincent Marchetti <<a href="mailto:vmarchetti@kshell.com" target="_blank">vmarchetti@kshell.com</a>> <br>
Sent: Monday, June 12, 2023 6:55 AM<br>
To: X3D-Public <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
Cc: Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>>; <a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>;<br>
Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>><br>
Subject: Re: [x3d-public] Problem in x3dviewscene: ROUTE placement<br>
<br>
Thank you for identifying the relevant seection of the X3D V4 Architecture.<br>
The relevant sentence from section 4.4.8.2 is:<br>
<br>
ROUTE statements may either appear at the top level of an X3D file or inside<br>
a node wherever fields may appear.<br>
<br>
It declares the intent of allowing a ROUTE statement inside a node<br>
definition in close proximity to a field that the ROUTE modifies, for<br>
purpose of readability, but other than that purpose this placement of the<br>
ROUTE statement does not change the semantics of a ROUTE statement. I don't<br>
think this sentence bears being taken literally to an extreme; otherwise we<br>
are obligated to define a additional XML encoding of the ROUTE statement<br>
which allows the ROUTE statement to be included as an XML attribute; so<br>
that, for example, it can be placed adjacent to the XML encoding of the<br>
SFVec3f "translation" field of the Transform element. I am not trying to<br>
argue by exaggeration;t I am argujng that the sentence need to be<br>
interpreted in accordance with the syntax of a specific encoding.<br>
<br>
The ClassicVRML encoding does allow a ROUTE to be defined in the body of a<br>
X3D node; the specific issue we are discussing is whether this includes<br>
placing the ROUTE definition inside the ClassicVRML encoding of an MFNode<br>
value. We could have a continued discussion about whether inclusion as an<br>
item in a MFNode value is included in the text phrase "..wherever fields may<br>
appear", but we can also refer to the formal grammar definition of the<br>
ClassicVRML appendix which, in my judgement, does not allow that.<br>
<br>
Taking a step back, and asuming that the JoeLevel2LOA3SSPYRWRJKHud.x3dv<br>
example was generated by a tool; we have one tool that generates an x3dv<br>
file which does not conform to the ClassicVRML formal geometry published in<br>
X3D V3.3 . If I understand Don's email report of June 9, the X3D conversion<br>
of the x3dv file passed validation, but this was not direct validation of<br>
the original x3dv file. So I see the validation situation as:<br>
<br>
1) The view3dscene code identifies the ClassicVRML error in<br>
JoeLevel2LOA3SSPYRWRJKHud.x3dv when asked to render it,'<br>
2) The conversion code, from x3dv -> x3d, offered by view3dscene, does not<br>
flag an error in JoeLevel2LOA3SSPYRWRJKHud.x3dv but does generate a valid<br>
x3d scene from it,<br>
<br>
In the example archives, we have not yet identified a ClassicVRML encoding<br>
that includes this very specific feature, a ROUTE statement included within<br>
an MFNode value of an X3D field, so it is not yet possible to use our<br>
example archive for guidance.<br>
<br>
I think these considerations make it premature to change the ClassicVRML<br>
grammar definition in the standard.<br>
<br>
Vince Marchetti<br>
<br>
<br>
<br>
> On Jun 12, 2023, at 1:36 AM, Brutzman, Donald (Don) (CIV)<br>
<<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br>
><br>
> . Sorry to be unclear, that was not the relevant reference, rather<br>
the prior email in the thread.<br>
><br>
> My mail of 9 June 16:30:04 PDT 2023 holds the relevant reference. Excerpt<br>
follows, quoting a quote, and have provided yellow highlights to key<br>
phrasing this time.<br>
><br>
><br>
> . [x3d-public] Problem in x3dviewscene: ROUTE placement<br>
> . <br>
> <a href="http://web3d.org/pipermail/x3d-public_web3d.org/2023-June/018836.html" rel="noreferrer" target="_blank">http://web3d.org/pipermail/x3d-public_web3d.org/2023-June/018836.html</a><br>
><br>
> The intent for ROUTE is that it might appear within other nodes. The <br>
> phrasing in X3D4 Architecture is quite explicit about this:<br>
><br>
> * X3D 4.0 Part 1: Architecture and base components, clause 4 Concepts, <br>
> 4.4.8.2 Routes<br>
> * <br>
> <a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.pr" rel="noreferrer" target="_blank">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.pr</a><br>
> oof/Part01/concepts.html#Routes<br>
><br>
> * Routes allows an author to declaratively connect the output events<br>
> of a node to input events of other nodes, providing a way to implement <br>
> complex behaviors without imperative programming. When a routed output <br>
> event is fired, the corresponding destination input event receives <br>
> notification and can process a response to that change. This <br>
> processing can change the state of the node, generate additional <br>
> events, or change the structure of the scene graph. Routes may be <br>
> created declaratively in an X3D file or programmatically via an SAI call.<br>
> * Routes are not nodes. The ROUTE statement is a construct for<br>
> establishing event paths between specified fields of nodes. ROUTE <br>
> statements may either appear at the top level of an X3D file or inside <br>
> a node wherever fields may appear. A ROUTE statement shall only appear <br>
> after the definition of the source and destination nodes. Placing a <br>
> ROUTE statement within a node does not associate it with that node in <br>
> any way. A ROUTE statement does follow the name scoping rules as described<br>
in 4.4.7 Run-time name scope.<br>
><br>
><br>
> . I next took the offered example scene<br>
> . <br>
> <a href="https://www.web3d.org/x3d/content/examples/Vrml2Sourcebook/Chapter08An" rel="noreferrer" target="_blank">https://www.web3d.org/x3d/content/examples/Vrml2Sourcebook/Chapter08An</a><br>
> imatingPositionOrientationScale/Figure08_3PositionInterpolator.x3d<br>
><br>
> and moved entire scene graph within Scene inside a Group, i.e.<br>
> . <Scene><Group><!-everything including ROUTE statements<br>
--></Group></Scene><br>
> . Thus nothing remains in top-level MFNode list of the scene, <br>
> except for single parent Group<br>
><br>
> Then tested the modified example.<br>
> . All validation tests passed.<br>
> . Xj3D worked.<br>
> . X3DOM worked.<br>
> . After 10 minutes of reporting to Microsoft that view3dscene was<br>
legitimate, and coercing Windows 10 to accept it, view3dscene.exe worked on<br>
this modified example too.<br>
> . Searching for "<ROUTE" found 4989 matches in first 500 scenes<br>
searched (out of 4060 total archived scenes) so no doubt there are more.<br>
><br>
> . To my prior list of benefits for flexible placement of ROUTE<br>
statements, here is another:<br>
> . Simplifies author and tool addition of code-block patterns and <br>
> templates within a scene (this a feature used numerous times as an<br>
optional authoring assist for event tracing by X3D-Edit, likely to be added<br>
as utility features in X3DJSAIL and X3DPSAIL someday as well.) Specifically,<br>
from X3D-Edit documentation,<br>
> . Trace capabilities are available for ROUTE, sensors, interpolators<br>
and other nodes that produce or consume events. Trace output results are<br>
logged on the browser console to show the timing and values passed events.<br>
When the Trace checkbox is selected by the author, a Script node is inserted<br>
immediately after the node to accomplish this task. This is a useful<br>
debugging technique.<br>
> .<br>
<a href="https://savage.nps.edu/X3D-Edit/images/TraceFeatureReportsRoutedEventValuesOnBrowserConsoleViaScriptOutput.png" rel="noreferrer" target="_blank">https://savage.nps.edu/X3D-Edit/images/TraceFeatureReportsRoutedEventValuesO<br>
nBrowserConsoleViaScriptOutput.png</a><br>
> . <br>
> <a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dg" rel="noreferrer" target="_blank">https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dg</a><br>
> <a href="http://raphics.com" rel="noreferrer" target="_blank">raphics.com</a>%2Fexamples%2FX3dForWebAuthors%2FChapter07-EventAnimationIn<br>
> terpolation%2FChapter07-EventAnimationInterpolation-EventTracing.pdf&d<br>
> ata=05%7C01%7Cbrutzman%<a href="http://40nps.edu" rel="noreferrer" target="_blank">40nps.edu</a>%7Cb515ffeb60984a05234408db6b4c930f%7C<br>
> 6d936231a51740ea9199f7578963378e%7C0%7C0%7C638221749492217739%7CUnknow<br>
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC<br>
> JXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=n5qX6WFQpMk%2B9TA0ov2HkR1qAdy3XCpzW<br>
> qlySYoMc44%3D&reserved=0<br>
><br>
> . "Consistency across all file encodings and language bindings is<br>
possible." This is our basic design principle for separation of<br>
functionality in X3D architecture from implementation details in all related<br>
specifications.<br>
><br>
> We have immense interoperability already. As promised many times, we will<br>
smooth out any mismatches in future X3D 4.0 file encodings and language<br>
bindings. Test cases do help too. So stand by for action.<br>
><br>
> Hopefully the highlighted specification requirement, the ease of creating<br>
flexible test cases, and the value of this existing specification capability<br>
is presented more clearly now.<br>
><br>
> Careful consideration, implementation efforts, and consensus-based<br>
progress are always appreciated.<br>
><br>
> Having fun with X3D. I hope that others are too.<br>
><br>
> all the best, Don<br>
> --<br>
> Don Brutzman Naval Postgraduate School, Code USW/Br<br>
<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA<br>
+1.831.656.2149<br>
> X3D graphics, virtual worlds, navy robotics <br>
> <a href="https://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">https://faculty.nps.edu/brutzman</a><br>
><br>
> From: <a href="mailto:vmarchetti@kshell.com" target="_blank">vmarchetti@kshell.com</a> <<a href="mailto:vmarchetti@kshell.com" target="_blank">vmarchetti@kshell.com</a>><br>
> Sent: Sunday, June 11, 2023 4:42 PM<br>
> To: Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>>; X3D-Public <br>
> <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
> Cc: Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>><br>
> Subject: Re: [x3d-public] Problem in x3dviewscene: ROUTE placement<br>
><br>
><br>
> On Jun 11, 2023, at 5:09 PM, Brutzman, Donald (Don) (CIV)<br>
<<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br>
><br>
> Not trying to invent anything here, rather point out what is specified<br>
(and also common practice). I already gave the relevant links in the X3D<br>
4.0 Architecture governing what is required.<br>
><br>
> I do not see this requirement given or even implied in the link you<br>
specified:<br>
> . <br>
> <a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.pr" rel="noreferrer" target="_blank">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.pr</a><br>
> oof/Part01/fieldTypes.html<br>
><br>
> is a comprehensive listing of the X3D Field types, with details on SFNode<br>
and MFNode therein, and on this page I don't see any mention of the ROUTE<br>
statement nor does a text search on that page discover even the terms<br>
"route" or "statement" in isolation.<br>
><br>
> ...<br>
><br>
><br>
> Consistency across all file encodings and language bindings is possible.<br>
> I don't this this statement is true, or to the extent that it is true, <br>
> then long - ago X3D design decisions did not treat it as of primary <br>
> importance. As Michalis pointed out, in the ClassicVRML encoding the <br>
> zero or more items in a single MFNode value are syntactically enclosed <br>
> in square brackets. Moreover, in the ClassicVRML encoding all the <br>
> field values are explicitly identified with the name of the field. <br>
> However, in the X3D encoding the XML child elements are in most cases <br>
> identified as belonging to an X3D field through the node <br>
> type-inheritance classification; and in the few cases where that is <br>
> not possible an explicit "containerField" XML attribute is used. To <br>
> make the X3D encoding consistent with ClassicVRML would entail the use <br>
> of wrapper XML elements around the element encoding of one <br>
> node-element for an SFNode value, or the several nodes of MFNode. <br>
> However, the design decision was made long ago not to use wrapper <br>
> elements in the XML encoding ( see <br>
> <a href="https://www.web3d.org/x3d/content/examples/Basic/development/WrapperTa" rel="noreferrer" target="_blank">https://www.web3d.org/x3d/content/examples/Basic/development/WrapperTa</a><br>
> gsConsideredHarmful.html )<br>
><br>
> My point is that the consistency among encodings is a useful criteria but<br>
should not automatically take precedence over other considerations. One such<br>
consideration is maintainging stability of our formal ClassicVRML grammar.<br>
><br>
> And I think there is little additional benefit in changing the the<br>
ClassicVRML to allow ROUTE inside MFNode encodings. Doing so does allow a<br>
ROUTE to be placed adjacent to a node whose fields it modifies and you (Don)<br>
have pointed out the readability benefits that offers -- but Michalis points<br>
out that the ClassicVRML already allows that ROUTE statement to be placed<br>
inside the body of a node it modifies, even closer!<br>
><br>
> Vince Marchetti<br>
<br>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div></div>