[x3d-public] Problem in x3dviewscene: ROUTE placement

[John Carlson]

I’m further remembering perhaps that these many routes were placed into a
JSON array of routes?

It’s been a very long time, I would have to recheck.

Water under the bridge?
On Sat, Jun 10, 2023 at 1:58 PM John Carlson <yottzumm at gmail.com> wrote:

> My impression was that they were being moved out (from a nested context)
> or down the scenegraph, collecting many routes together.
>
> I didn’t write X3dToJson.xslt.  It’s not my expertise, but i may be able
> to find some examples with roundtripping.
>
> It would be easy to test by sprinkling many routes at same level in XML,
> then convert to JSON to see if they are collected.  I hope this helps.
>
> HAnim is higher priority.
>
> John
>
> On Sat, Jun 10, 2023 at 1:45 PM Brutzman, Donald (Don) (CIV) <
> brutzman at nps.edu> wrote:
>
>> Good question, not sure where they are getting moved.  Examples always
>> welcome.  When JSON Schema is finally approved and implemented, we’ll be
>> able to formalize that.
>>
>>
>>
>>    - X3D Resources, Examples: Scene Archives for X3D
>>    -
>>    https://www.web3d.org/x3d/content/examples/X3dResources.html#Examples
>>
>>
>>
>> Expectation is that ordering of nodes and ROUTE statements will be
>> consistent for ClassicVRML, XML, JSON, Java, Python, etc., allowing
>> symmetric conversion between representations.  Hence the careful scrutiny
>> as we go.  Thanks for tracking this John.
>>
>>
>>
>> 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:* John Carlson <yottzumm at gmail.com>
>> *Sent:* Saturday, June 10, 2023 11:28 AM
>> *To:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>> *Cc:* Michalis Kamburelis <michalis.kambi at gmail.com>; X3D Graphics
>> public mailing list <x3d-public at web3d.org>
>> *Subject:* Re: [x3d-public] Problem in x3dviewscene: ROUTE placement
>>
>>
>>
>> Don, does this make it so we don’t have to move routes around in the JSON
>> encoding?
>>
>>
>>
>> I was not clear why they needed to be moved.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> John
>>
>>
>>
>> On Sat, Jun 10, 2023 at 1:05 PM Brutzman, Donald (Don) (CIV) <
>> brutzman at nps.edu> wrote:
>>
>> Well, closer, but not quite there yet.  Here is some more “language
>> lawyering.”  8)
>>
>>
>>
>> BLUF: it is important and allowed for ROUTE statements (and prototype
>> statements) to appear in MFNode lists, side by side with other nodes.
>>
>>
>>
>> Not exactly sure what you mean by MFList.  Presumably you mean MFNode,
>> which is one of the approved concrete or abstract types in
>>
>>
>>
>>    - X3D 4.0 Part 1: Architecture and base components, clause 5 Field
>>    type reference
>>    -
>>    https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/fieldTypes.html
>>
>>
>>
>> I believe that the rules are telling us that the ROUTE statement can
>> appear where other nodes can appear.  Typically that is within an MFNode
>> list.
>>
>>
>>
>>    - X3D 4.0 Part 1: Architecture and base components, clause 5 Field
>>    type reference, 5.3 Field types, 5.3.12 SFNode and MFNode
>>    -
>>    https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/fieldTypes.html#SFNodeAndMFNode
>>    - The SFNode field specifies an X3D node. The MFNode field specifies
>>    zero or more nodes.
>>    - The default value of an uninitialized SFNode field is NULL. The
>>    default value of an MFNode field is the empty list.
>>
>>
>>
>> The third bullet above likely needs to be modified to say
>>
>>    - The SFNode field specifies an X3D node. The MFNode field specifies
>>    zero or more nodes, also allowing ROUTE or prototype statements.
>>
>>
>>
>> Also relevant, with another suggested addition, again providing clarity
>> and consistency with 4.4.8.2 Routes and 4.4.4 Prototype semantics:
>>
>>    - 5.2.2 X3DArrayField
>>    - X3DArrayField is the abstract field type from which all field types
>>    that can contain multiple values are derived. All fields derived from
>>    X3DArrayField have names beginning with *MF* (multiple-valued field).
>>    MF fields may zero or more values, each of which shall be of the type
>>    indicated by the corresponding SF field type. It is illegal for any MF
>>    field to mix values of different SF field types.  An MFNode field can
>>    also include ROUTE and prototype statements.
>>    - 5.2.3 X3DField
>>    - X3DField is the abstract field type from which all single values
>>    field types are derived. All fields directly derived from X3DField have
>>    names beginning with *SF* (single-valued field). SF fields may only
>>    contain a single value of the type indicated by the name of the field type.
>>
>>
>>
>> Corresponding ClassicVRML grammar productions:
>>
>>    - X3D 3.3 encodings, Part 2: Classic VRML encoding, Annex A
>>    (normative) Grammar, A.2 General
>>    -
>>    https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html#General
>>
>>
>> *statements *::=
>>
>> *statement *|
>>
>> *statement statements *|
>>
>> *empty *;
>>
>> *statement *::=
>>
>> *nodeStatement* |
>> *importStatement* |
>> *exportStatement |*
>>
>> *protoStatement* |
>>
>> *routeStatement* ;
>>
>> *nodeStatement *::=
>>
>> *node* |
>>
>> *DEF **nodeNameId node* |
>>
>> *USE** nodeNameId* ;
>>
>>
>>
>> IMPORT and EXPORT statements only appear in special locations related to
>> Inline node usage, and don’t seem to need special mention in the prose
>> above.
>>
>>
>>
>> We certainly have many hundreds of validated examples that include ROUTE
>> statements along with other children nodes, as part of MFNode lists.  Large
>> parts of our existing infrastructure support this construct, in accordance
>> with X3D Architecture.
>>
>>
>>
>> Bottom line: it is important and allowed for ROUTE statements (and
>> prototype statements) to appear in MFNode lists, side by side with other
>> nodes.
>>
>>
>>
>> If the two highlighted sentences above seem like useful additions, I’ll
>> create a Mantis issue and we can inquire if ISO editors will accept such a
>> change at this very late date.
>>
>>
>>
>> Again thanks for careful scrutiny.  Looking forward to regaining full
>> consensus on this important design issue which is critical to consistent
>> X3D model interoperability.
>>
>>
>>
>> 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: Michalis Kamburelis <michalis.kambi at gmail.com>
>> Sent: Friday, June 9, 2023 4:46 PM
>> To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>> Cc: Joseph D Williams <joedwil at earthlink.net>; X3D Graphics public
>> mailing list <x3d-public at web3d.org>; puk at igraphics.com
>> Subject: Re: [x3d-public] Problem in x3dviewscene: ROUTE placement
>>
>>
>>
>> I do not see any need to change the X3D spec here. For once, it is all
>> correct in X3D spec  :) And "Architecture and base components" is
>> consistent with what "Classic VRML encoding" is saying, and both chapters
>> of "Classic VRML encoding" ("4 Concepts" and "Annex A
>>
>> (normative) Grammar") are consistent.
>>
>>
>>
>> Joe's model should just be fixed, from what I can tell -- you have to
>> move ROUTE outside of the [ ... ]. It makes sense that MFList [ ... ]
>> should contain only nodes.
>>
>>
>>
>> From what I can tell,
>>
>>
>> https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html
>>
>> clearly says that ROUTE cannot be part of MFList [ ... ] , and that's OK.
>> You have to place ROUTE within some node (or at top-level).
>>
>>
>>
>> Within MFList [ ... ] you can only have nodes (or USE of nodes). You
>> cannot place ROUTE, EXPORT, IMPORT, PROTO... within MFList [ ... ] and
>> that's OK, that's simple. Let's not break it :)
>>
>>
>>
>> Regards,
>>
>> Michalis
>>
>>
>>
>> sob., 10 cze 2023 o 01:30 Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>> napisał(a):
>>
>> >
>>
>> > Thanks for precise response Michalis, very helpful.
>>
>> >
>>
>> > 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.
>>
>> >
>>
>> > We expect that the prose and grammar in 19776-2/V3.3 Part 2: Classic
>> VRML encoding to be reviewed and refined to match, when we get back to that
>> document and upgrade it to X3D 4.0.  I think that the current ClassicVRML
>> spec indeed defers to the Architecture specification:
>>
>> >
>>
>> > X3D 3.3 Part 2: Classic VRML encoding, clause 4 Concepts, 4.3.2
>>
>> > Statements, 4.3.2.1 Organization of statements “Any number of ROUTE
>> statements as specified in 4.4.8.2 Routes of ISO/IEC 19775-1.”
>>
>> >
>>
>> > So changes (corresponding to your accurate note) may need to be made to
>>
>> >
>>
>> > X3D 3.3 Part 2: Classic VRML encoding, Annex A (normative), Grammar
>>
>> > https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/gra
>> mmar.html
>>
>> >
>>
>> >
>>
>> >
>>
>> > Wikipedia: Extended Backus–Naur form (EBNF)
>>
>> > https://en.wikipedia.org/wiki/Extended_Backus-Naur_form
>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FExtended_Backus-Naur_form&data=05%7C01%7Cbrutzman%40nps.edu%7C00db1b0e43bf45f74e9b08db69e07595%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638220185033281771%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7WB1UD%2BKA76sWVHgZGKmKzv76f%2BIUr6Rof%2FC%2BvLENfY%3D&reserved=0>
>>
>> >
>>
>> >
>>
>> > which includes the following EBNF production rules:
>>
>> >
>>
>> >
>>
>> >
>>
>> > node ::=
>>
>> >
>>
>> > nodeTypeId { nodeBody } |
>>
>> >
>>
>> > Script { scriptBody } |
>>
>> >
>>
>> > ComposedShader {composedShaderBody} |
>>
>> > PackagedShader {packagedShaderBody} |
>>
>> > ShaderProgram {shaderProgramBody} ;
>>
>> >
>>
>> > nodeBody ::=
>>
>> >
>>
>> > nodeBodyElement |
>>
>> >
>>
>> > nodeBodyElement nodeBody |
>>
>> >
>>
>> > empty ;
>>
>> >
>>
>> > nodeBodyElement ::=
>>
>> >
>>
>> > initializeOnlyId fieldValue |
>>
>> > inputOutputId fieldValue |
>>
>> >
>>
>> > initializeOnlyId IS initializeOnlyId |
>>
>> >
>>
>> > inputOnlyId IS inputOnlyId |
>>
>> >
>>
>> > outputOnlyId IS outputOnlyId |
>>
>> >
>>
>> > inputOutputId IS inputOutputId |
>>
>> >
>>
>> > routeStatement |
>>
>> >
>>
>> > protoStatement ;
>>
>> >
>>
>> > and
>>
>> >
>>
>> > routeStatement ::=
>>
>> >
>>
>> > ROUTE nodeNameId . outputOnlyId TO nodeNameId . inputOnlyId ;
>>
>> >
>>
>> >
>>
>> >
>>
>> > which, at first glance, looks OK to me from perspective of Joe’s
>>
>> > example (and many other examples)…
>>
>> >
>>
>> >
>>
>> >
>>
>> > Do you have modifications to suggest for the grammar?
>>
>> >
>>
>> >
>>
>> >
>>
>> > p.s. I tried to add a Mantis issue for long-term tracking but had
>> trouble getting form to respond properly, will try again another time.
>>
>> >
>>
>> > Ensure ClassicVRML grammar matches X3D 4.0 Architecture Concepts and
>> rules.
>>
>> > In particular, closely examine placement of ROUTE statements.
>>
>> >
>>
>> >
>>
>> >
>>
>> > 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: Michalis Kamburelis <michalis.kambi at gmail.com>
>>
>> > Sent: Friday, June 9, 2023 2:11 PM
>>
>> > To: Joseph D Williams <joedwil at earthlink.net>
>>
>> > Cc: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; X3D Graphics
>>
>> > public mailing list <x3d-public at web3d.org>
>>
>> > Subject: Re: [x3d-public] Problem in x3dviewscene: ROUTE placement
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > The ROUTE cannot go anywhere in the file, in particular you cannot
>> place it inside an MFNode.
>>
>> >
>>
>> >
>>
>> >
>>
>> > https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/con
>>
>> > cepts.html
>>
>> >
>>
>> > : ROUTE is allowed at top-level and in node's body,
>>
>> >
>>
>> >
>>
>> >
>>
>> > """
>>
>> >
>>
>> > A node's body consists of any number of field statements, IS
>> statements, ROUTE statements, PROTO statements or EXTERNPROTO statements,
>> in any order.
>>
>> >
>>
>> > """
>>
>> >
>>
>> >
>>
>> >
>>
>> > The grammar confirms this precisely:
>>
>> >
>>
>> >
>>
>> >
>>
>> > https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/gra
>>
>> > mmar.html
>>
>> >
>>
>> > :
>>
>> >
>>
>> >
>>
>> >
>>
>> > - mfnodeValue is a sequence of nodeStatement
>>
>> >
>>
>> > - nodeStatement is only "USE ...", "DEF Xxx Node { }" or "Node { }"
>>
>> >
>>
>> > - only the more general "statement" allows ROUTE (and IMPORT, EXPORT,
>> PROTO...). The "statement" is inside a node (but not in MFNode list).
>>
>> >
>>
>> >
>>
>> >
>>
>> > Regards,
>>
>> >
>>
>> > Michalis
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > pt., 9 cze 2023 o 22:37 Joseph D Williams <joedwil at earthlink.net>
>> napisał(a):
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > Hi All,
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > My problem with view3dscene 4.3.0 is that it quits reading upon this
>> sequence:
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > DEF StandAnimation Group {
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > children [
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > DEF StandTimer TimeSensor { … }
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > DEF Stand_r_metatarsalPitch OrientationInterpolator {
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >   key [ … ]
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >   keyValue [ ... ]} ...
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > ROUTE StandTimer.fraction_changed TO
>>
>> >
>>
>> > > Stand_r_ankleRotInterp.set_fraction
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > ]}
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > …
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > When it finds a ROUTE as child of Group. The error is:
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > VRML/X3D: Error when reading, will skip the rest of X3D file:
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > Error at line 661 column 6:
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > Expected node type or DEF or USE, got keyword "ROUTE"
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > Making this construction required.
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > DEF StandAnimation Group {
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > children [
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > DEF StandTimer TimeSensor { … }
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > DEF Stand_r_metatarsalPitch OrientationInterpolator {
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >   key [ … ]
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >   keyValue [ ... ]} ...
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > ]}
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > ROUTE StandTimer.fraction_changed TO
>>
>> >
>>
>> > > Stand_r_ankleRotInterp.set_fraction
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > …
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > Moving the Route outside the Group.
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > I think we went through the gram in detail here and found that
>> placing the statement in this MF should be OK.
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > Thanks,
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > Joe
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > Clipped for mercy
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > From: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of Joseph
>>
>> > > D
>>
>> >
>>
>> > > Williams
>>
>> >
>>
>> > > Sent: Friday, June 9, 2023 10:29 AM
>>
>> >
>>
>> > > To: X3D Graphics public mailing list <x3d-public at web3d.org>
>>
>> >
>>
>> > > Subject: [x3d-public] Problem in x3dviewscene: ROUTE placement
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > Error in viewX3dScene processing
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > VRML/X3D: Error when reading, will skip the rest of X3D file: Error
>> at line 661 column 6: Expected node type or DEF or USE, got keyword "ROUTE"
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > I was hoping we could fix this player problem since we determined
>> that a ROUTE statement can go anywhere in the file.
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > Thanks,
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > Joe
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> >
>>
>> > >
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230610/30419a76/attachment-0001.html>