[x3d-public] Problem in x3dviewscene: ROUTE placement
Brutzman, Donald (Don) (CIV)
brutzman at nps.edu
Sat Jun 10 11:04:09 PDT 2023
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/Pa
rt01/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/Pa
rt01/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.h
tml#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>
https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.h
tml
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) <
<mailto:brutzman at nps.edu> 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>
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>
https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.h
tml
>
>
>
> Wikipedia: Extended Backus-Naur form (EBNF)
> https://en.wikipedia.org/wiki/Extended_Backus-Naur_form
>
>
> 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
<mailto:brutzman at nps.edu> 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> https://faculty.nps.edu/brutzman
>
>
>
> -----Original Message-----
> From: Michalis Kamburelis < <mailto:michalis.kambi at gmail.com>
michalis.kambi at gmail.com>
> Sent: Friday, June 9, 2023 2:11 PM
> To: Joseph D Williams < <mailto:joedwil at earthlink.net>
joedwil at earthlink.net>
> Cc: Brutzman, Donald (Don) (CIV) < <mailto:brutzman at nps.edu>
brutzman at nps.edu>; X3D Graphics
> public mailing list < <mailto:x3d-public at web3d.org> 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>
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>
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 < <mailto:joedwil at earthlink.net>
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 < <mailto:x3d-public-bounces at web3d.org>
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 < <mailto:x3d-public at web3d.org>
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
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230610/b301f928/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5464 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230610/b301f928/attachment-0001.p7s>
More information about the x3d-public
mailing list