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