[x3d-public] Where to allow ROUTE in X3D models? Deep-dive analysis
Brutzman, Donald (Don) (CIV)
brutzman at nps.edu
Sun Nov 5 20:49:59 PST 2023
Glad this careful look was useful, thanks.
FWIW for authoring cases where I wanted to ROUTE into a Material node, the moving the ROUTE a few lines later (just after the containing Shape node) didn’t seem like any significant loss of authoring context. Good DEF names help even further.
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: Andreas Plesch <andreasplesch at gmail.com>
Sent: Sunday, November 5, 2023 9:28 AM
To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
Cc: GPU Group <gpugroup at gmail.com>; Holger Seelig <holger.seelig at yahoo.de>; Michalis Kamburelis <michalis.kambi at gmail.com>; X3D Graphics public mailing list <x3d-public at web3d.org>
Subject: Re: Where to allow ROUTE in X3D models? Deep-dive analysis
NPS WARNING: *external sender* verify before acting.
Thanks for the deep dive into X3D design and the xml encoding.
I completely agree that all the diverse X3D statements have their own requirements within the document. So a MFStatement type field type would not be useful.
Good to learn that the XML encoding restricts ROUTE placement to the Scene root and to within X3DGroupingNodes via the schema. If this is the case, that restriction should probably be included in the XML encoding specification itself, perhaps here https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#ROUTEStatementSyntax .
In turn, since the XML encoding has this restriction, other encodings may also need to consider such a restriction since content should be transparent across encodings. In the end, the abstract specification may need to be tightened from 'inside a node wherever fields may appear' to something like 'inside a node wherever X3DChildNodes may appear'.
Finally, to me a ROUTE statement next to a Material node (inside a Shape node) does not seem out of place, if an author wants to emphasize the target of an event. An author could reasonably structure a scene document following an input-processing-output design: First, a (Time)Sensor as input, then an Interpolator ( or Script ) for processing, and finally the Shape with the Material as output at the bottom. That does not seem very exotic ?
But if such a ROUTE statement placement is deemed not desirable in any encoding, I think the spec. should reflect that view and may need another look.
All the best, Andreas
On Sat, Nov 4, 2023 at 9:09 PM Brutzman, Donald (Don) (CIV) <brutzman at nps.edu <mailto:brutzman at nps.edu> > wrote:
All useful thoughts, thanks Andreas and Doug.
I have been down this design path too. Thanks to several years of X3D Working Group development and discussion on this x3d-public list, here is where we have currently landed.
1. X3D Statements are defined by the X3D Architecture specification. We use that, and of course will not be changing that in the foreseeable future. The spec sayeth:
* X3D 4.0 Architecture, clause 7 Core component, 7.2.5 Abstract X3D structure, 7.2.5.1 Organization
* https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/components/core.html#AbstractX3DStructure
An X3D world is conceptually defined as a sequence of nodes and statements organized as a file. The first item in the file is the Header statement. The second item in the file is the PROFILE statement. The PROFILE statement may be optionally followed by one or more COMPONENT, UNIT and/or META statements in that order. There may be multiple of each of the COMPONENT, UNIT, and/or META statements. The remainder of the file consists of the other elements (nodes and statements) defined in this document .
X3D statements include the following:
* Header,
* PROFILE,
* COMPONENT,
* META,
* UNIT,
* ROUTE,
* PROTO declare,
* EXTERNPROTO declare,
* PROTO interface,
* PROTO body,
* IS,
* connect,
* IMPORT, and
* EXPORT
As one explores the specification, it is pretty clear that each of these statements is handled differently. There are no “abstract types for statements” provided in the specification. Also please note that none of the statements can be a root node, since statements are not nodes, but several of the statements are allowed to appear next to root nodes.
2. Next. One can find all of the X3D statements defined in X3D XML Schema (for scene validation). For example,
* X3D Specifications: Schema and DOCTYPE Validation
* https://www.web3d.org/specifications/
* X3D XML Schema x3d-4.0.xsd and documentation (latest)
* https://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0.html
* https://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0_X3D.html
* https://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0_component.html
* https://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0_unit.html
* https://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0_meta.html
* https://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0_ROUTE.html
* etc.
Because statements vary widely in where they can appear, the parent-child relationships (aka content model) also varies widely.
Due to XML Schema expressiveness sometimes resulting in combinatoric explosion, it was only generally only practical/possible to allow ROUTE to appear either at the top of a Scene or within an X3DGroupingNode. So, for example, let’s check those closely. Please look at those parent-child relationship diagrams that include ROUTE:
* https://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0_Scene.html (wow, a lot of possibilities)
* down towards bottom: ChildContentModelSceneGraphStructure
and
* https://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0_X3DGroupingNode.html
* again towards bottom, can find ChildContentModelSceneGraphStructure
* https://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0_ChildContentModelSceneGraphStructure.html
You can also ponder the X3D XML Schema source directly if you prefer. The documentation is generated from that, so we have good confidence that it all works.
3. So far so good… Next, these hierarchical object-oriented XML Schema definitions are then transformed and applied to create flatter, more readable X3DUOM.
Let’s look in detail at how the statements got collected in X3DUOM.
* X3D Unified Object Model (X3DUOM)
* https://www.web3d.org/specifications/X3DUOM.html
* https://www.web3d.org/specifications/X3dUnifiedObjectModel-4.0.xml
* Overall structure (screen snippet using Chrome)
* Under <Statements> have excerpted the X3DUOM definition for the ROUTE statement on line 42832 (currently). (The appinfo documentation originates from the X3D Tooltips.)
<Statement name="ROUTE">
<InterfaceDefinition specificationUrl=https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/concepts.html#ModifyingObjectsRoutes
appinfo="ROUTE connects output fields of event-producing nodes to input fields of event-consuming nodes.">
<componentInfo name="Core" level="1"/>
<field name="class"
type="SFString"
accessType="inputOutput"
inheritedFrom="X3DStatement"
baseType="xs:NMTOKENS"
description="The class attribute on each X3D node and statement is a space-separated list of classes, reserved for use by Cascading Style Sheets (CSS) and XML stylesheets."/>
<field name="fromField"
type="SFString"
accessType="inputOutput"
use="required"
baseType="xs:NMTOKEN"
description="fromField is the field name in the source node which is originating an event."/>
<field name="fromNode"
type="SFString"
accessType="inputOutput"
use="required"
baseType="xs:IDREF"
description="fromNode is the DEF name of the node originating an event."/>
<field name="id"
type="SFString"
accessType="inputOutput"
inheritedFrom="X3DStatement"
baseType="xs:NMTOKEN"
description="The id attribute on each X3D node and statement is considered a unique identifier when used as part of an encompassing HTML/DOM context."/>
<field name="style"
type="SFString"
accessType="inputOutput"
inheritedFrom="X3DStatement"
description="The style attribute on each X3D node and statement provides an inline block of CSS source for element styling, reserved for use by Cascading Style Sheets (CSS) and XML stylesheets."/>
<field name="toField"
type="SFString"
accessType="inputOutput"
use="required"
baseType="xs:NMTOKEN"
description="toField is the field name in the destination node which is receiving an event."/>
<field name="toNode"
type="SFString"
accessType="inputOutput"
use="required"
baseType="xs:IDREF"
description="toNode is the DEF name of the destination node receiving an event."/>
</InterfaceDefinition>
</Statement>
Continued exploration shows consistent structures throughout X3DUOM. Autogeneration is challenging but powerful!
Every single one of these X3D data products listed in this message is open source, published freely, and maintained up to date in one of our Web3D Consortium version-control archives. Nerdy perhaps but cool, definitely!
4. XML Schema validation of thousands of models in the X3D Example Archives has really shaken out a lot of problems and edge cases.
Validation testing of ClassicVRML versions using view3dscene tovrmlx3d.exe from Castle Game Engine is finding further X3D 4.0 model issues and fixes, collaboration work with Michalis is still in progress on that.
Autogenerating Java, Python and Turtle from X3DUOM has given us further validation testing. Periodic revisions and releases follow meaningful improvements.
Am keen to get going on investigating Holger’s identification of X3DUOM mismatches with his code and presumably the authoritative reference, X3D Architecture.
5. OK OK already. Where can you put a ROUTE?
One might well think “well let’s put a ROUTE inside of any other parent node.” In theory, maybe.
In practice, not usually. When modeling the actual X3D scene, sticking a ROUTE somewhere within a Shape node didn’t seem to help an author at all, since none of the other nodes within Shape actually generate events. Much better to put the ROUTE after the DEF’ed interpolator/sensor/script node, since all DEF’s must be defined first.
So trying to sprinkle ROUTE statements with reckless abandon anywhere in an X3D model seems like an impractical goal, maybe a case of
* Patient: “Doctor Doctor, my arm hurts when I lift it far behind my back like this…. over here… Ouch!”
* Doctor: “Don’t do that.”
* In NYC: “That will be a thousand dollars, please!” (more pain follows…)
And so, how does that pain-filled joke relate? Well, making our XML/ClassicVRML/Java/Python/Turtle and JSON/ECMAScript/C/C/C++ SAI interfaces and (where possible) VRML97 models all consistent, compatible and round-trippable seems still like a very worthy, most-excellent, achievable implementation goal for X3D 4.0. No really.
The journey continues. I think we will have a very productive 2024 together aligning all of these X3D 4.0 variations to a consistent theme, updating each of our many specifications and implementations to match the finalized reference (cue trumpets please):
* Extensible 3D (X3D) 4.0, Part 1: Architecture and base components
* https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/Architecture.html
Any way you like it, hopefully, if we remain careful. Repeatable improvements are always welcome.
Have fun with X3D 4.0! 8)
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu <mailto: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: Andreas Plesch <andreasplesch at gmail.com <mailto:andreasplesch at gmail.com> >
Sent: Friday, November 3, 2023 7:44 PM
To: GPU Group <gpugroup at gmail.com <mailto:gpugroup at gmail.com> >
Cc: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu <mailto:brutzman at nps.edu> >; X3D Graphics public mailing list <x3d-public at web3d.org <mailto:x3d-public at web3d.org> >
Subject: Re: [x3d-public] x3d.py roundtrip for Metadata nodes in v.3.3 and v.4.0
On Thu, Nov 2, 2023 at 7:48 PM GPU Group < <mailto:gpugroup at gmail.com> gpugroup at gmail.com> wrote:
>
> Proposed solution: MFStatement field type in x3d.py
> - each executionContext type ProtoDeclare, Inline, Scene would have 2
> new fields MFStatement ProtoDeclares MFStatement Routes
Although at first it seems incongruent to have fields with statement type values, it is not really different from say a color type. So I think that makes sense.
Should then Shape also have an MFStatement Routes field ? In fact, since Routes can occur wherever fields occur, all nodes would need such a field, since all nodes have fields.
> - then when exporting a scene via x3d.py, protodeclares and routes
> would be put in those fields
> - x3d.py when writing an execution context to a file would put protodeclares at the top and routes at the bottom.
I also seem to remember that Don had discussed putting Routes in the children parameter for x3d.py earlier, as something which is mostly sufficient. The generated XML/VRML is still valid, there is only an issue if there is an appetite for complete equivalence between all encodings, eg. complete roundtrips xml - python - xml.
containerField support in x3d.py is really unrelated and can be accomplished in any case.
-Andreas
>
> On Thu, Nov 2, 2023 at 7:42 AM GPU Group < <mailto:gpugroup at gmail.com> gpugroup at gmail.com> wrote:
>>
>> What about on Scene/Proto/Inline executionContext - is there an array holder / property / sub-element for ProtoDeclares and one for Routes in those x3d.py elements? If so, then they (ProtoDeclares, Routes) could go there.
>> -Doug
>>
>>
>> On Wed, Nov 1, 2023 at 8:54 PM Andreas Plesch < <mailto:andreasplesch at gmail.com> andreasplesch at gmail.com> wrote:
>>>
>>> Hi Don,
>>>
>>> All true and relevant, of course. I think the important phrase is
>>> "inside a node wherever fields may appear". The question becomes
>>> what does that phrase mean for the python encoding ? It is unclear
>>> that it means ROUTE statements should appear as members of the array
>>> which is assigned to the children field of a node, or any other
>>> MFNode field of a node. The python encoding does not currently allow
>>> for non-field parameters to appear inside a X3D node, eg. inside the
>>> parameters given to the node returning function call. So, as a
>>> consequence, the only option currently is to add ROUTE statements to
>>> MFNode field values in the python encoding which to me seems more like a band aid.
>>> For example, it seems to make it impossible to represent a ROUTE
>>> inside a node which only has SFNode fields like:
>>>
>>> XML:
>>> <Shape>
>>> <Appearance>
>>> <Material DEF='boxColor' diffuseColor='1 0 0' />
>>> </Appearance>
>>> <ROUTE fromNode='cIntrpltr' fromField='value_changed'
>>> toNode='boxColor' toField='diffuseColor' />
>>> <Box/>
>>> </Shape>
>>>
>>> Python:
>>> Shape(
>>> appearance=Appearance(
>>> material=Material(DEF='boxColor', diffuseColor=SFColor(1,0,0))),
>>> # How to add a ROUTE here ?
>>> # children=[ ROUTE(..) ] ?
>>> geometry=Box()
>>> )
>>>
>>> Perhaps the children parameter is allowed for any node in the Python encoding ?
>>>
>>> Would it make sense to add a 'statements' parameter or an 'inside'
>>> parameter to node generating functions in python ? Possibly too late
>>> for that.
>>>
>>> In any case, for containerField support it is possible to just have
>>> Route.XML() (and Comment.XML()) accept an optional field parameter
>>> which is ignored.
>>>
>>> -Andreas
>>>
>>> On Wed, Nov 1, 2023 at 8:03 PM Brutzman, Donald (Don) (CIV)
>>> < <mailto:brutzman at nps.edu> brutzman at nps.edu> wrote:
>>> >
>>> > Checking details: placement of ROUTE (and several other X3D statements) is allowed as a child of X3DGroupingNode and is permitted by XML validation.
>>> >
>>> >
>>> >
>>> > As noted already, we will be similarly working to make each of the file encodings and programming language bindings as symmetric as possible to maximize X3D 4.0 portability and clarity.
>>> >
>>> >
>>> >
>>> > Of course it is a well-known error pattern to have missing or unclear ROUTE definitions. The ability to keep ROUTEs together with (i.e. promptly following) related nodes is an excellent pattern for author understanding and animation completeness. There are almost-countless instances of this pattern in the X3D Example Archives.
>>> >
>>> >
>>> >
>>> > Finally, this was a deliberately considered topic during working group meetings and X3D 4.0 development. Note that the following example in X3D 4.0 does not state it must be at root of the scene.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > X3D 4.0 Architecture, clause 4 Concepts, 4.4.2.4.1 Routes
>>> > <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-I> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-I
>>> > S.proof/Part01/concepts.html#ModifyingObjectsRoutes
>>> >
>>> >
>>> >
>>> > EXAMPLE It is possible to create a scene with run-time behavior using only this event propagation model:
>>> >
>>> >
>>> >
>>> > DEF TS TimeSensor {
>>> >
>>> > loop TRUE
>>> >
>>> > cycleInterval 5
>>> >
>>> > }
>>> >
>>> > DEF I PositionInterpolator {
>>> >
>>> > key [ 0 0.5 1 ]
>>> >
>>> > keyValue [ 0 -1 0, 0 1 0, 0 -1 0 ]
>>> >
>>> > }
>>> >
>>> > DEF T Transform {
>>> >
>>> > children [
>>> >
>>> > Shape {
>>> >
>>> > geometry Box { }
>>> >
>>> > }
>>> >
>>> > ]
>>> >
>>> > }
>>> >
>>> > ROUTE ts.fraction_changed TO I.set_fraction
>>> >
>>> > ROUTE I.value_changed TO T.set_translation
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > Also relevant:
>>> >
>>> >
>>> >
>>> > X3D 4.0 Architecture, clause 4 Concepts, 4.4.8.2 Routes
>>> > <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-I> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-I
>>> > S.proof/Part01/concepts.html#Routes
>>> > Excerpt: “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.”
>>> >
>>> >
>>> >
>>> > Hope this makes sense. Thanks everyone for paying close attention… validatable correctness is essential.
>>> >
>>> >
>>> >
>>> > Have fun with X3D! 8)
>>> >
>>> >
>>> >
>>> > 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: x3d-public < <mailto:x3d-public-bounces at web3d.org> x3d-public-bounces at web3d.org> On Behalf Of
>>> > Andreas Plesch
>>> > Sent: Wednesday, November 1, 2023 12:36 PM
>>> > To: John Carlson < <mailto:yottzumm at gmail.com> yottzumm at gmail.com>
>>> > Cc: X3D Graphics public mailing list < <mailto:x3d-public at web3d.org> x3d-public at web3d.org>
>>> > Subject: Re: [x3d-public] x3d.py roundtrip for Metadata nodes in
>>> > v.3.3 and v.4.0
>>> >
>>> >
>>> >
>>> > I think that is because JoeKick.py puts ROUTE in the children field of a Group node which is not quite correct. ROUTEs can be children elements in the XML encoding but are not valid values for the children field. I think in the python encoding ROUTEs can probably exist only at the Scene level to avoid conflating x3d children with xml children.
>>> >
>>> >
>>> >
>>> > x3dcf2.py may work more robustly since the stylesheet does not really distinguish between x3d nodes and x3d statements and it did add the field parameter also to ROUTE.XML(). Perhaps give it a try.
>>> >
>>> >
>>> >
>>> > -Andreas
>>> >
>>> >
>>> >
>>> > On Wed, Nov 1, 2023 at 1:35 PM John Carlson < <mailto:yottzumm at gmail.com> yottzumm at gmail.com> wrote:
>>> >
>>> > >
>>> >
>>> > > First "bug" report:
>>> >
>>> > >
>>> >
>>> > > $ py JoeKick.py
>>> >
>>> > > x3d.py package 4.0.64.4 loaded, have fun with X3D Graphics!
>>> >
>>> > > Self-test diagnostics for JoeKick.py:
>>> >
>>> > > meta information, TODO: Record information about skin
>>> > > coordinates
>>> >
>>> > > (found in comment at end of scene) as a structured MetadataSet containing MetadataString nodes Traceback (most recent call last):
>>> >
>>> > > File "C:\Users\john\X3DJSONLD\blend\JoeKick.py", line 715, in
>>> > > <module>
>>> >
>>> > > newModelXML= newModel.XML() # test export method XML() for
>>> > > exceptions during export
>>> >
>>> > > ^^^^^^^^^^^^^^
>>> >
>>> > > File "C:\Users\john\x3d-python-mod\x3dcf.py", line 14985, in
>>> > > XML
>>> >
>>> > > result += str(self.Scene.XML(indentLevel=indentLevel+1,
>>> > > syntax=syntax))
>>> >
>>> > >
>>> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> >
>>> > > File "C:\Users\john\x3d-python-mod\x3dcf.py", line 14494, in
>>> > > XML
>>> >
>>> > > result += each.XML(indentLevel=indentLevel+1, syntax=syntax)
>>> >
>>> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> >
>>> > > File "C:\Users\john\x3d-python-mod\x3dcf.py", line 45024, in
>>> > > XML
>>> >
>>> > > result += each.XML(indentLevel=indentLevel+1, syntax=syntax,
>>> > > field="children")
>>> >
>>> > >
>>> >
>>> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> > > ^^^^
>>> >
>>> > > TypeError: ROUTE.XML() got an unexpected keyword argument 'field'
>>> >
>>> > >
>>> >
>>> > > I have to take a half hour off volunteering, I hope to be back soon.
>>> >
>>> > >
>>> >
>>> > > John
>>> >
>>> > >
>>> >
>>> > > On Wed, Nov 1, 2023 at 12:22 PM Andreas Plesch < <mailto:andreasplesch at gmail.com> andreasplesch at gmail.com> wrote:
>>> >
>>> > >>
>>> >
>>> > >> Thanks for giving this a try ! Glad to hear it could be useful,
>>> >
>>> > >>
>>> >
>>> > >> Andreas
>>> >
>>> > >>
>>> >
>>> > >> > Message: 2
>>> >
>>> > >> > Date: Wed, 1 Nov 2023 11:16:24 -0400
>>> >
>>> > >> > From: Vincent Marchetti < <mailto:vmarchetti at kshell.com> vmarchetti at kshell.com>
>>> >
>>> > >> > To: X3D-Public < <mailto:x3d-public at web3d.org> x3d-public at web3d.org>
>>> >
>>> > >> > Subject: Re: [x3d-public] x3d.py roundtrip for Metadata nodes
>>> > >> > in v.3.3
>>> >
>>> > >> > and v.4.0
>>> >
>>> > >> > Message-ID: < <mailto:38B8549E-944D-460F-B5D7-31BC73721015 at kshell.com> 38B8549E-944D-460F-B5D7-31BC73721015 at kshell.com>
>>> >
>>> > >> > Content-Type: text/plain; charset="us-ascii"
>>> >
>>> > >> >
>>> >
>>> > >> > Thank you Andreas, The x3dcf.py module is a useful tool for generating X3D XML encoding for those scenes which require the containerField xml attribute to unambiguously assign XML elements to the different X3D fields of the parent XML element.
>>> >
>>> > >> >
>>> >
>>> > >> > I ran an example Python script for generating a MetadataSet node that required containerField for accurat XML encoding and the correct result is in the GeneratedCalendarMetadataWithCF.x3d file attached.
>>> >
>>> > >> >
>>> >
>>> > >> > The pertinent accurate encoding is:
>>> >
>>> > >> > ------
>>> >
>>> > >> > <WorldInfo>
>>> >
>>> > >> > <MetadataSet containerField='metadata' name='birthday'
>>> > >> > reference='https://www.archives.gov/legislative/features/wash
>>> > >> > ington'>
>>> >
>>> > >> > <MetadataString containerField='metadata'
>>> > >> > name='calendar' value='"Julian"'/>
>>> >
>>> > >> > <MetadataInteger containerField='value' name='day'
>>> > >> > value='11'/>
>>> >
>>> > >> > <MetadataInteger containerField='value' name='month'
>>> > >> > value='2'/>
>>> >
>>> > >> > <MetadataInteger containerField='value' name='year'
>>> > >> > value='1731'/>
>>> >
>>> > >> > </MetadataSet>
>>> >
>>> > >> > </WorldInfo>
>>> >
>>> > >> >
>>> >
>>> > >> > -----
>>> >
>>> > >> >
>>> >
>>> > >> > Vince Marchetti
>>> >
>>> > >> >
>>> >
>>> > >> > -------------- next part -------------- A non-text attachment
>>> > >> > was
>>> >
>>> > >> > scrubbed...
>>> >
>>> > >> > Name: GenerateCalendarMetadataWithCF.py
>>> >
>>> > >> > Type: text/x-python-script
>>> >
>>> > >> > Size: 791 bytes
>>> >
>>> > >> > Desc: not available
>>> >
>>> > >> > URL:
>>> >
>>> > >> > <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/
>>> > >> > 202311
>>> >
>>> > >> > 01/1383c745/attachment-0001.bin>
>>> >
>>> > >> > -------------- next part -------------- A non-text attachment
>>> > >> > was
>>> >
>>> > >> > scrubbed...
>>> >
>>> > >> > Name: GeneratedCalendarMetadataWithCF.x3d
>>> >
>>> > >> > Type: model/x3d+xml
>>> >
>>> > >> > Size: 920 bytes
>>> >
>>> > >> > Desc: not available
>>> >
>>> > >> > URL:
>>> >
>>> > >> > <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/
>>> > >> > 202311
>>> >
>>> > >> > 01/1383c745/attachment-0001.x3d>
>>> >
>>> > >> > -------------- next part --------------
>>> >
>>> > >> >
>>> >
>>> > >> >
>>> >
>>> > >> > > On Nov 1, 2023, at 10:23 AM, Andreas Plesch < <mailto:andreasplesch at gmail.com> andreasplesch at gmail.com> wrote:
>>> >
>>> > >> > >
>>> >
>>> > >> > > A quick update:
>>> >
>>> > >> > >
>>> >
>>> > >> > > On Tue, Oct 31, 2023 at 3:49?PM Andreas Plesch < <mailto:andreasplesch at gmail.com> andreasplesch at gmail.com> wrote:
>>> >
>>> > >> > >>
>>> >
>>> > >> > >> Notes:
>>> >
>>> > >> > >>
>>> >
>>> > >> > >> x3d.py is autogenerated from X3DUOM:
>>> >
>>> > >> > >>
>>> >
>>> > >> > >> <https://www.web3d.org/x3d/stylesheets/python/python.html#a> https://www.web3d.org/x3d/stylesheets/python/python.html#a
>>> > >> > >> utogen
>>> >
>>> > >> > >> eration
>>> >
>>> > >> > >> <https://nam10.safelinks.protection.outlook.com/?url=https%25> https://nam10.safelinks.protection.outlook.com/?url=https%
>>> > >> > >> 3A%2F%
>>> >
>>> > >> > >> 2Fsourceforge.net%2Fp%2Fx3d%2Fcode%2FHEAD%2Ftree%2Fwww.web
>>> > >> > >> 3d.org <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2F3d.org%2F&data=05%7C01%7Cbrutzman%40nps.edu%7C9f41ab9794284336382508dbde24943e%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638348020996493248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yUcr0PzRQs1m3YcoP88aCDjVL6bf7UPwCq%2FzayoSU1c%3D&reserved=0>
>>> >
>>> > >> > >> %2Fx3d%2Fstylesheets%2FX3duomToX3dPythonPackage.xslt&data=
>>> > >> > >> 05%7C0
>>> >
>>> > >> > >> 1%7Cbrutzman%40nps.edu <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2F40nps.edu%2F&data=05%7C01%7Cbrutzman%40nps.edu%7C9f41ab9794284336382508dbde24943e%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638348020996493248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Z9uIuTyggvaHbvHNc68vcXEzZJ%2FYBA4pINI0eaRZyH4%3D&reserved=0> %7Ccd2d5f56ffc7496e3e5b08dbdb11f7fb%
>>> > >> > >> 7C6d93
>>> >
>>> > >> > >> 6231a51740ea9199f7578963378e%7C0%7C0%7C638344642474548323%
>>> > >> > >> 7CUnkn
>>> >
>>> > >> > >> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
>>> > >> > >> TiI6Ik
>>> >
>>> > >> > >> 1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vUoJQilvuatDOWA
>>> > >> > >> pbTvcw
>>> >
>>> > >> > >> vEprn8iyCs%2B%2F%2F7xTlQxpYE%3D&reserved=0
>>> >
>>> > >> > >>
>>> >
>>> > >> > >> X3DUOM has all necessary containerField default value information.
>>> >
>>> > >> > >>
>>> >
>>> > >> > >> But the first step may be to modify the stylesheet to
>>> > >> > >> generate
>>> >
>>> > >> > >> containerField attributes for all nodes, for simplicity.
>>> > >> > >> It
>>> >
>>> > >> > >> looks like the .XML() function would have to have an additional parameter 'field'
>>> >
>>> > >> > >> X3D(indentLevel, syntax, field) for each node.
>>> >
>>> > >> > >>
>>> >
>>> > >> > >> Postprocessing the generated XML is not possible since
>>> >
>>> > >> > >> information was irretrievably lost. But postprocessing the
>>> >
>>> > >> > >> autogenerated x3d.py python code may be possible since xslt is not for everyone.
>>> >
>>> > >> > >
>>> >
>>> > >> > > As a proof of concept I hacked a short awk (since I know
>>> > >> > > it)
>>> >
>>> > >> > > script to process the latest x3d.py to include containerField support:
>>> >
>>> > >> > >
>>> >
>>> > >> > > <https://nam10.safelinks.protection.outlook.com/?url=https%253> https://nam10.safelinks.protection.outlook.com/?url=https%3
>>> > >> > > A%2F%2
>>> >
>>> > >> > > Fgithub.com%2Fandreasplesch%2Fx3d-python-mod%2Fblob%2Fmain%
>>> > >> > > 2Fsrc%
>>> >
>>> > >> > > 2FcfXML.awk&data=05%7C01%7Cbrutzman%40nps.edu <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2F40nps.edu%2F&data=05%7C01%7Cbrutzman%40nps.edu%7C9f41ab9794284336382508dbde24943e%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638348020996493248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Z9uIuTyggvaHbvHNc68vcXEzZJ%2FYBA4pINI0eaRZyH4%3D&reserved=0> %7Ccd2d5f56ffc
>>> > >> > > 7496e3
>>> >
>>> > >> > > e5b08dbdb11f7fb%7C6d936231a51740ea9199f7578963378e%7C0%7C0%
>>> > >> > > 7C6383
>>> >
>>> > >> > > 44642474548323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
>>> > >> > > LCJQIj
>>> >
>>> > >> > > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd
>>> > >> > > ata=6X
>>> >
>>> > >> > > xOQrg8Id5BdOwqnW52BBFwDkmMPwhgKsa2BLle6ms%3D&reserved=0
>>> >
>>> > >> > >
>>> >
>>> > >> > > It looks for the Concrete Nodes section, adds a field
>>> > >> > > parameter
>>> >
>>> > >> > > to the
>>> >
>>> > >> > > .XML() output function, adds the containerField attribute
>>> > >> > > to the
>>> >
>>> > >> > > output, and adds the field parameter to the .XML() calls
>>> > >> > > for
>>> >
>>> > >> > > metadata, SFNode and MFNode field processing.
>>> >
>>> > >> > > The awk script is very brittle since it relies on comments
>>> > >> > > in
>>> >
>>> > >> > > x3d.py to find the appropriate lines to modify. The hardest
>>> > >> > > part
>>> >
>>> > >> > > was to get the quoting and escaping correct.
>>> >
>>> > >> > > It generates containerField attributes for all SF/MFNode
>>> > >> > > fields
>>> >
>>> > >> > > except 'children'. Of course, most are unnecessary but
>>> > >> > > filtering
>>> >
>>> > >> > > systematically for defaults would probably require
>>> > >> > > involving
>>> >
>>> > >> > > X3DUOM and the generation stylesheet, similar to other XML related 'fields'
>>> >
>>> > >> > > such as style or class.
>>> >
>>> > >> > >
>>> >
>>> > >> > > The result is
>>> >
>>> > >> > > <https://nam10.safelinks.protection.outlook.com/?url=https%253> https://nam10.safelinks.protection.outlook.com/?url=https%3
>>> > >> > > A%2F%2
>>> >
>>> > >> > > Fraw.githubusercontent.com <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Ffraw.githubusercontent.com%2F&data=05%7C01%7Cbrutzman%40nps.edu%7C9f41ab9794284336382508dbde24943e%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638348020996493248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5OgXIoMgqLfe8aWJugWz9uJ94v3pp46GWs7pVcJQXaA%3D&reserved=0> %2Fandreasplesch%2Fx3d-python-mod
>>> > >> > > %2Fmai
>>> >
>>> > >> > > n%2Fx3dcf.py&data=05%7C01%7Cbrutzman%40nps.edu <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2F40nps.edu%2F&data=05%7C01%7Cbrutzman%40nps.edu%7C9f41ab9794284336382508dbde24943e%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638348020996649960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4BNBFzXRFlC3neEIuVH0qqIAdSiW2gSZLBcxen%2BZ0Fo%3D&reserved=0> %7Ccd2d5f56ff
>>> > >> > > c7496e
>>> >
>>> > >> > > 3e5b08dbdb11f7fb%7C6d936231a51740ea9199f7578963378e%7C0%7C0
>>> > >> > > %7C638
>>> >
>>> > >> > > 344642474548323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
>>> > >> > > iLCJQI
>>> >
>>> > >> > > joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
>>> > >> > > data=p
>>> >
>>> > >> > > Lm5kiuYmgbb5jcjp09KTCrIzUt2p%2BkdYlrjyYpkhac%3D&reserved=0
>>> >
>>> > >> > >
>>> >
>>> > >> > > The modified python script appears to work as expected by
>>> > >> > > adding
>>> >
>>> > >> > > the appropriate containerField attributes in XML output for
>>> > >> > > all
>>> >
>>> > >> > > the examples I tried.
>>> >
>>> > >> > > Realistically, this is as far as I can go with this but I
>>> > >> > > think
>>> >
>>> > >> > > it may show how containerField support in XML output could
>>> > >> > > be
>>> >
>>> > >> > > provided with x3d.py.
>>> >
>>> > >> > >
>>> >
>>> > >> > > -Andreas
>>> >
>>> > >> > >
>>> >
>>> > >> > > _______________________________________________
>>> >
>>> > >> > > x3d-public mailing list
>>> >
>>> > >> > > <mailto:x3d-public at web3d.org> x3d-public at web3d.org
>>> >
>>> > >> > > <http://web3d.org/mailman/listinfo/x3d-public_web3d.org> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>> >
>>> > >> >
>>> >
>>> > >> >
>>> >
>>> > >> > ------------------------------
>>> >
>>> > >> >
>>> >
>>> > >> > Message: 3
>>> >
>>> > >> > Date: Wed, 1 Nov 2023 11:05:29 -0500
>>> >
>>> > >> > From: John Carlson < <mailto:yottzumm at gmail.com> yottzumm at gmail.com>
>>> >
>>> > >> > To: Andreas Plesch < <mailto:andreasplesch at gmail.com> andreasplesch at gmail.com>
>>> >
>>> > >> > Cc: X3D Graphics public mailing list < <mailto:x3d-public at web3d.org> x3d-public at web3d.org>
>>> >
>>> > >> > Subject: Re: [x3d-public] x3d.py roundtrip for Metadata nodes
>>> > >> > in v.3.3
>>> >
>>> > >> > and v.4.0
>>> >
>>> > >> > Message-ID:
>>> >
>>> > >> >
>>> >
>>> > >> > <CAGC3UEkYxP0tk5rQ23VVhsd0gXW7W+AH5QaS=AWxkv0f8kgo1Q at mail.gma
>>> > >> > il.com <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fil.com%2F&data=05%7C01%7Cbrutzman%40nps.edu%7C9f41ab9794284336382508dbde24943e%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638348020996649960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=M6LTAtabU93ocuw8%2FpCHdSUIIDIx57krThmVjaxsczg%3D&reserved=0>
>>> >
>>> > >> > >
>>> >
>>> > >> > Content-Type: text/plain; charset="utf-8"
>>> >
>>> > >> >
>>> >
>>> > >> > You are awesome, Andreas! Awk would not have been my choice,
>>> > >> > but
>>> >
>>> > >> > apparently, you made it work! Perhaps I will make a Perl
>>> > >> > script based on
>>> >
>>> > >> > your awk. A python script could be written to process X3DUOM and probably
>>> >
>>> > >> > do the matching as well.
>>> >
>>> > >> >
>>> >
>>> > >> > Dang cool!
>>> >
>>> > >> >
>>> >
>>> > >> > On Wed, Nov 1, 2023 at 9:24 AM Andreas Plesch
>>> >
>>> > >> > < <mailto:andreasplesch at gmail.com> andreasplesch at gmail.com>
>>> >
>>> > >> > wrote:
>>> >
>>> > >> >
>>> >
>>> > >> > > A quick update:
>>> >
>>> > >> > >
>>> >
>>> > >> > > On Tue, Oct 31, 2023 at 3:49?PM Andreas Plesch
>>> >
>>> > >> > > < <mailto:andreasplesch at gmail.com> andreasplesch at gmail.com>
>>> >
>>> > >> > > wrote:
>>> >
>>> > >> > > >
>>> >
>>> > >> > > > Notes:
>>> >
>>> > >> > > >
>>> >
>>> > >> > > > x3d.py is autogenerated from X3DUOM:
>>> >
>>> > >> > > >
>>> >
>>> > >> > > > <https://www.web3d.org/x3d/stylesheets/python/python.html> https://www.web3d.org/x3d/stylesheets/python/python.html#
>>> > >> > > > autoge
>>> >
>>> > >> > > > neration
>>> >
>>> > >> > > >
>>> >
>>> > >> > > <https://nam10.safelinks.protection.outlook.com/?url=https%253> https://nam10.safelinks.protection.outlook.com/?url=https%3
>>> > >> > > A%2F%2
>>> >
>>> > >> > > Fsourceforge.net%2Fp%2Fx3d%2Fcode%2FHEAD%2Ftree%2Fwww.web3d
>>> > >> > > .org%2
>>> >
>>> > >> > > Fx3d%2Fstylesheets%2FX3duomToX3dPythonPackage.xslt&data=05%
>>> > >> > > 7C01%7
>>> >
>>> > >> > > Cbrutzman%40nps.edu <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2F40nps.edu%2F&data=05%7C01%7Cbrutzman%40nps.edu%7C9f41ab9794284336382508dbde24943e%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638348020996649960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4BNBFzXRFlC3neEIuVH0qqIAdSiW2gSZLBcxen%2BZ0Fo%3D&reserved=0> %7Ccd2d5f56ffc7496e3e5b08dbdb11f7fb%7C6d
>>> > >> > > 936231
>>> >
>>> > >> > > a51740ea9199f7578963378e%7C0%7C0%7C638344642474548323%7CUnk
>>> > >> > > nown%7
>>> >
>>> > >> > > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
>>> > >> > > 1haWwi
>>> >
>>> > >> > > LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vUoJQilvuatDOWApbTvcwv
>>> > >> > > Eprn8i
>>> >
>>> > >> > > yCs%2B%2F%2F7xTlQxpYE%3D&reserved=0
>>> >
>>> > >> > > >
>>> >
>>> > >> > > > X3DUOM has all necessary containerField default value information.
>>> >
>>> > >> > > >
>>> >
>>> > >> > > > But the first step may be to modify the stylesheet to
>>> > >> > > > generate
>>> >
>>> > >> > > > containerField attributes for all nodes, for simplicity.
>>> > >> > > > It
>>> >
>>> > >> > > > looks like the .XML() function would have to have an additional parameter 'field'
>>> >
>>> > >> > > > X3D(indentLevel, syntax, field) for each node.
>>> >
>>> > >> > > >
>>> >
>>> > >> > > > Postprocessing the generated XML is not possible since
>>> >
>>> > >> > > > information was irretrievably lost. But postprocessing
>>> > >> > > > the
>>> >
>>> > >> > > > autogenerated x3d.py python code may be possible since xslt is not for everyone.
>>> >
>>> > >> > >
>>> >
>>> > >> > > As a proof of concept I hacked a short awk (since I know
>>> > >> > > it)
>>> >
>>> > >> > > script to process the latest x3d.py to include containerField support:
>>> >
>>> > >> > >
>>> >
>>> > >> > > <https://nam10.safelinks.protection.outlook.com/?url=https%253> https://nam10.safelinks.protection.outlook.com/?url=https%3
>>> > >> > > A%2F%2
>>> >
>>> > >> > > Fgithub.com%2Fandreasplesch%2Fx3d-python-mod%2Fblob%2Fmain%
>>> > >> > > 2Fsrc%
>>> >
>>> > >> > > 2FcfXML.awk&data=05%7C01%7Cbrutzman%40nps.edu <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2F40nps.edu%2F&data=05%7C01%7Cbrutzman%40nps.edu%7C9f41ab9794284336382508dbde24943e%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638348020996649960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4BNBFzXRFlC3neEIuVH0qqIAdSiW2gSZLBcxen%2BZ0Fo%3D&reserved=0> %7Ccd2d5f56ffc
>>> > >> > > 7496e3
>>> >
>>> > >> > > e5b08dbdb11f7fb%7C6d936231a51740ea9199f7578963378e%7C0%7C0%
>>> > >> > > 7C6383
>>> >
>>> > >> > > 44642474548323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
>>> > >> > > LCJQIj
>>> >
>>> > >> > > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd
>>> > >> > > ata=6X
>>> >
>>> > >> > > xOQrg8Id5BdOwqnW52BBFwDkmMPwhgKsa2BLle6ms%3D&reserved=0
>>> >
>>> > >> > >
>>> >
>>> > >> > > It looks for the Concrete Nodes section, adds a field
>>> > >> > > parameter
>>> >
>>> > >> > > to the
>>> >
>>> > >> > > .XML() output function, adds the containerField attribute
>>> > >> > > to the
>>> >
>>> > >> > > output, and adds the field parameter to the .XML() calls
>>> > >> > > for
>>> >
>>> > >> > > metadata, SFNode and MFNode field processing.
>>> >
>>> > >> > > The awk script is very brittle since it relies on comments
>>> > >> > > in
>>> >
>>> > >> > > x3d.py to find the appropriate lines to modify. The hardest
>>> > >> > > part
>>> >
>>> > >> > > was to get the quoting and escaping correct.
>>> >
>>> > >> > > It generates containerField attributes for all SF/MFNode
>>> > >> > > fields
>>> >
>>> > >> > > except 'children'. Of course, most are unnecessary but
>>> > >> > > filtering
>>> >
>>> > >> > > systematically for defaults would probably require
>>> > >> > > involving
>>> >
>>> > >> > > X3DUOM and the generation stylesheet, similar to other XML related 'fields'
>>> >
>>> > >> > > such as style or class.
>>> >
>>> > >> > >
>>> >
>>> > >> > > The result is
>>> >
>>> > >> > > <https://nam10.safelinks.protection.outlook.com/?url=https%253> https://nam10.safelinks.protection.outlook.com/?url=https%3
>>> > >> > > A%2F%2
>>> >
>>> > >> > > Fraw.githubusercontent.com <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Ffraw.githubusercontent.com%2F&data=05%7C01%7Cbrutzman%40nps.edu%7C9f41ab9794284336382508dbde24943e%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638348020996649960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iFL32%2F0st2d%2F%2Bnceewc0%2BCMYOJOLSbcuCHSaNqkuYB4%3D&reserved=0> %2Fandreasplesch%2Fx3d-python-mod
>>> > >> > > %2Fmai
>>> >
>>> > >> > > n%2Fx3dcf.py&data=05%7C01%7Cbrutzman%40nps.edu <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2F40nps.edu%2F&data=05%7C01%7Cbrutzman%40nps.edu%7C9f41ab9794284336382508dbde24943e%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638348020996649960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4BNBFzXRFlC3neEIuVH0qqIAdSiW2gSZLBcxen%2BZ0Fo%3D&reserved=0> %7Ccd2d5f56ff
>>> > >> > > c7496e
>>> >
>>> > >> > > 3e5b08dbdb11f7fb%7C6d936231a51740ea9199f7578963378e%7C0%7C0
>>> > >> > > %7C638
>>> >
>>> > >> > > 344642474704621%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
>>> > >> > > iLCJQI
>>> >
>>> > >> > > joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
>>> > >> > > data=7
>>> >
>>> > >> > > 4nwRmIni6cSY%2FMdNtOH5VNh9l6%2FScsR4te6XOlwKug%3D&reserved=
>>> > >> > > 0
>>> >
>>> > >> > >
>>> >
>>> > >> > > The modified python script appears to work as expected by
>>> > >> > > adding
>>> >
>>> > >> > > the appropriate containerField attributes in XML output for
>>> > >> > > all
>>> >
>>> > >> > > the examples I tried.
>>> >
>>> > >> > > Realistically, this is as far as I can go with this but I
>>> > >> > > think
>>> >
>>> > >> > > it may show how containerField support in XML output could
>>> > >> > > be
>>> >
>>> > >> > > provided with x3d.py.
>>> >
>>> > >> > >
>>> >
>>> > >> > > -Andreas
>>> >
>>> > >> > >
>>> >
>>> > >> > -------------- next part -------------- An HTML attachment
>>> > >> > was
>>> >
>>> > >> > scrubbed...
>>> >
>>> > >> > URL:
>>> >
>>> > >> > <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/
>>> > >> > 202311
>>> >
>>> > >> > 01/59b1f34d/attachment.html>
>>> >
>>> > >> >
>>> >
>>> > >> > ------------------------------
>>> >
>>> > >> >
>>> >
>>> > >> > Subject: Digest Footer
>>> >
>>> > >> >
>>> >
>>> > >> > _______________________________________________
>>> >
>>> > >> > x3d-public mailing list
>>> >
>>> > >> > <mailto:x3d-public at web3d.org> x3d-public at web3d.org
>>> >
>>> > >> > <http://web3d.org/mailman/listinfo/x3d-public_web3d.org> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>> >
>>> > >> >
>>> >
>>> > >> >
>>> >
>>> > >> > ------------------------------
>>> >
>>> > >> >
>>> >
>>> > >> > End of x3d-public Digest, Vol 176, Issue 4
>>> >
>>> > >> > ******************************************
>>> >
>>> > >>
>>> >
>>> > >>
>>> >
>>> > >>
>>> >
>>> > >> --
>>> >
>>> > >> Andreas Plesch
>>> >
>>> > >> Waltham, MA 02453
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> > Andreas Plesch
>>> >
>>> > Waltham, MA 02453
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> >
>>> > x3d-public mailing list
>>> >
>>> > <mailto:x3d-public at web3d.org> x3d-public at web3d.org
>>> >
>>> > <http://web3d.org/mailman/listinfo/x3d-public_web3d.org> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>
>>>
>>>
>>> --
>>> Andreas Plesch
>>> Waltham, MA 02453
>>>
>>> _______________________________________________
>>> x3d-public mailing list
>>> <mailto:x3d-public at web3d.org> x3d-public at web3d.org
>>> <http://web3d.org/mailman/listinfo/x3d-public_web3d.org> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
--
Andreas Plesch
Waltham, MA 02453
--
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20231106/9efd85d2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3155 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20231106/9efd85d2/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 24204 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20231106/9efd85d2/attachment-0003.png>
-------------- 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/20231106/9efd85d2/attachment-0001.p7s>
More information about the x3d-public
mailing list