[x3d-public] Statement permitted placements
Don Brutzman
brutzman at nps.edu
Fri Jul 14 10:19:16 PDT 2017
Great analysis, thanks for performing and sharing Roy.
Based on their functionality, we might also consider placing
- IMPORT/AS within the corresponding Inline, and
- EXPORT at the top level of a scene
However, we should be wary about that. Since scenes can be constructed programmatically, a tool might append an IMPORT or EXPORT at run time at other places in the scene graph.
We probably should also be deliberate whether to allow statements like (EXTERN)PROTODECLARE, ROUTE, IMPORT/EXPORT inside of Appearance and other non-children kinds of locations. Doesn't necessarily have to be there, but let's be consistent across encodings.
On 7/14/2017 8:45 AM, Roy Walmsley wrote:
> Hi,
>
> We were recently discussing the permitted placement of the following statements:
>
> ROUTE
>
> IMPORT
>
> EXPORT
>
> PROTODECLARE
>
> EXTERNPROTODECLARE
>
> The original discussion centred on the draft JSON encoding. However, I have now been looking at this in the XML and Classic VRML encodings.
>
> Let’s take a look at what is permitted by these encodings, and also compare what the abstract standard says.
>
> Let’s take the Classic VRML encoding first, i.e. ISO/IEC 19776-2 V3.3. The most comprehensive description is the grammar in Annex A.2.
>
> Reference: http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html#General
>
> A non-terminal “statement” is defined as:
>
> /nodeStatement/|
> /importStatement/ |
> /exportStatement /|
>
> /protoStatement/|
>
> /routeStatement/;
>
> The non-terminal “nodeStatement” can be followed down to “node”, “nodeBody”, and “nodeBodyElement”. This last non-terminal has the definition:
>
> /initializeOnlyId fieldValue/|
> /inputOutputId fieldValue |/
>
> /initializeOnlyId /*IS*/initializeOnlyId/|
>
> /inputOnlyId /*IS*/inputOnlyId/|
>
> /outputOnlyId /*IS*/outputOnlyId/|
>
> /inputOutputId /*IS*/inputOutputId/|
>
> /routeStatement/|
>
> /protoStatement/;
>
> Notice the lack or importStatement and exportStatement.
>
> This has been pointed out previously. In fact, Mantis issue 698 covers this very point.
>
> Reference: http://www.web3d.org/member-only/mantis/view.php?id=698
>
> Now let’s take the XML encoding, ISO/IEC 19776-1 V3.3. Let’s look at an example node, say Group, defined at 6.2.81.
>
> Reference: http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfNodes.html#Group
>
> Notice that this Node has a content model denoted by “ChildContentModel”. The description of this is given in 6.3.3 ChildContentModel
>
> Reference: http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfNodes.html#ChildContentModel
>
> The text states: “ChildContentModel is the child-node content model corresponding to X3DChildNode, combining all profiles. ChildContentModel can contain most nodes, other Grouping nodes, Prototype declarations and ProtoInstances in any order and any combination.”. Note that there is no mention of ROUTES, or IMPORT/EXPORT.
>
> We should also note the text in 6.3.5 ChildContentModelSceneGraphStructure.
>
> Reference: http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfNodes.html#ChildContentModelSceneGraphStructure
>
> This states “Child-node content model corresponding to SceneGraphStructure elements, which are not specific X3D nodes. These are ProtoDeclare, ExternProtoDeclare, IMPORT, EXPORT or ROUTE statements.”. This content model covers all the statements of interest. Where is it used? This content model is not listed in any node definition. In fact, it is not mentioned anywhere else in the standard.
>
> Turning to the XML schema V3.3 now.
>
> Reference: http://www.web3d.org/specifications/x3d-3.3.xsd
>
> Looking at the “Group” node, we see that the content model is derived from X3DGroupingNode. Looking at the definition for X3DGroupingNode, the following definition can be extracted:
>
> <xs:complexContent>
>
> <xs:extensionbase="X3DChildNode">
>
> <xs:sequenceminOccurs="0"maxOccurs="unbounded">
>
> <xs:annotation>
>
> <xs:documentation>children</xs:documentation>
>
> </xs:annotation>
>
> <xs:groupref="ChildContentModel"minOccurs="0"maxOccurs="unbounded"/>
>
> <xs:groupref="ChildContentModelSceneGraphStructure"minOccurs="0"maxOccurs="unbounded"/>
>
> </xs:sequence>
>
> <xs:attributename="bboxCenter"type="SFVec3f"default="0 0 0"/>
>
> <xs:attributename="bboxSize"type="boundingBoxSizeType"default="-1 -1 -1"/>
>
> </xs:extension>
>
> </xs:complexContent>
>
> So any node derived from X3DGroupingNode will be passed as valid of it has any of the statements we are considering. Where else if this content model used? The XML schema has six instances of this term, as follows:
>
> 1. In the definition of X3DGroupingNode
> 2. In the definition of the content model group ChildContentModelSceneGraphStructure
> 3. In the definition of the content model group GroupingNodeChildContentModel
> 4. In the definition of the content model group SceneGraphFragmentWithPrototypeDeclarationsContentModel
> 5. In the definition of the StaticGroup node
> 6. In the definition of the GeoLOD node
>
> The GroupingNodeChildContentModel is only used in the definition of the Scene element.
>
> So, we see that in the XML schema these statements are only permitted in grouping nodes.
>
> Finally, let us turn to the abstract standard ISO/IEC 19775-1 V3.3. What does it tell us about the placements of statements. There is no general text covering all the statements, so we need to look at each one in turn. We will start with ROUTEs and Prototypes, 7.2.5.7 ROUTE statement, 7.2.5.8 PROTO statement, and 7.2.5.9 EXTERNPROTO statement.
>
> Reference: http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#ROUTEStatement
>
> Reference: http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#PROTOStatement
>
> Reference: http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#EXTERNPROTOStatement
>
> All three of these clauses have the words “xxxxxx statements may appear anywhere in the file”
>
> Now look at 9.2.5 IMPORT statement, and 9.2.6 EXPORT statement.
>
> Reference: http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#IMPORTStatement
>
> Reference: http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#EXPORTStatement
>
> Neither of these clauses has any comment on the placement within the file.
>
> So, what do we conclude?
>
> 1. ROUTEs and prototypes are permitted anywhere.
> 2. IMPORT and EXPORT need a statement on placement in the abstract standard
>
> If we assume that A) is correct, then:
>
> 3. In the XML encoding the content models need to be amended to permit placement of these statements anywhere
> 4. In the Classic VRML encoding the grammar needs to be amended
>
> Of course, we might want to restrict the usage, in which case these needs proper definition in the abstract standard, and propagation to the encodings.
>
> All the best,
>
> Roy
>
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
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 http://faculty.nps.edu/brutzman
More information about the x3d-public
mailing list