[x3d-public] Problem in x3dviewscene: ROUTE placement
John Carlson
yottzumm at gmail.com
Sun Jun 25 10:51:29 PDT 2023
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/5e736351/attachment-0001.html>
More information about the x3d-public
mailing list