[x3d-public] x3d.py roundtrip for Metadata nodes in v.3.3 and v.4.0

Thu Nov 2 07:12:40 PDT 2023

My guess is, the Blender X3DV does/will do something similar.

John

On Thu, Nov 2, 2023 at 9:06 AM GPU Group <gpugroup at gmail.com> wrote:

> Freewrl scrapes protodeclares and routes out of the parsing stream and
> puts them in per-executionContext arrays, so they don't show up in the
> runtime scenegraph. If freewrl wrote out / exported an x3d/x3dv file, it
> would have no information about pretty-placement of those things, and would
> put ProtoDeclares at the top of executionContext before nodes and put
> routes at bottom of executionContext after nodes.
> -Dougs
>
> On Thu, Nov 2, 2023 at 7:42 AM GPU Group <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 <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)
>>> <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-IS.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-IS.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
>>> 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: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of Andreas
>>> Plesch
>>> > Sent: Wednesday, November 1, 2023 12:36 PM
>>> > To: John Carlson <yottzumm at gmail.com>
>>> > Cc: X3D Graphics public mailing list <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 <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 <
>>> 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 <vmarchetti at kshell.com>
>>> >
>>> > >> > To: X3D-Public <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: <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/washington'>
>>> >
>>> > >> >         <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 <
>>> andreasplesch at gmail.com> wrote:
>>> >
>>> > >> > >
>>> >
>>> > >> > > A quick update:
>>> >
>>> > >> > >
>>> >
>>> > >> > > On Tue, Oct 31, 2023 at 3:49?PM Andreas Plesch <
>>> andreasplesch at gmail.com> wrote:
>>> >
>>> > >> > >>
>>> >
>>> > >> > >> Notes:
>>> >
>>> > >> > >>
>>> >
>>> > >> > >> x3d.py is autogenerated from X3DUOM:
>>> >
>>> > >> > >>
>>> >
>>> > >> > >>
>>> https://www.web3d.org/x3d/stylesheets/python/python.html#autogen
>>> >
>>> > >> > >> eration
>>> >
>>> > >> > >>
>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%
>>> >
>>> > >> > >> 2Fsourceforge.net%2Fp%2Fx3d%2Fcode%2FHEAD%2Ftree%
>>> 2Fwww.web3d.org
>>> >
>>> > >> > >>
>>> %2Fx3d%2Fstylesheets%2FX3duomToX3dPythonPackage.xslt&data=05%7C0
>>> >
>>> > >> > >> 1%7Cbrutzman%40nps.edu
>>> %7Ccd2d5f56ffc7496e3e5b08dbdb11f7fb%7C6d93
>>> >
>>> > >> > >>
>>> 6231a51740ea9199f7578963378e%7C0%7C0%7C638344642474548323%7CUnkn
>>> >
>>> > >> > >>
>>> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
>>> >
>>> > >> > >>
>>> 1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vUoJQilvuatDOWApbTvcw
>>> >
>>> > >> > >> 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%3A%2F%2
>>> >
>>> > >> > >
>>> Fgithub.com%2Fandreasplesch%2Fx3d-python-mod%2Fblob%2Fmain%2Fsrc%
>>> >
>>> > >> > > 2FcfXML.awk&data=05%7C01%7Cbrutzman%40nps.edu
>>> %7Ccd2d5f56ffc7496e3
>>> >
>>> > >> > >
>>> e5b08dbdb11f7fb%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C6383
>>> >
>>> > >> > >
>>> 44642474548323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
>>> >
>>> > >> > >
>>> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=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%3A%2F%2
>>> >
>>> > >> > > Fraw.githubusercontent.com
>>> %2Fandreasplesch%2Fx3d-python-mod%2Fmai
>>> >
>>> > >> > > n%2Fx3dcf.py&data=05%7C01%7Cbrutzman%40nps.edu
>>> %7Ccd2d5f56ffc7496e
>>> >
>>> > >> > >
>>> 3e5b08dbdb11f7fb%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638
>>> >
>>> > >> > >
>>> 344642474548323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
>>> >
>>> > >> > >
>>> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=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
>>> >
>>> > >> > > x3d-public at 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 <yottzumm at gmail.com>
>>> >
>>> > >> > To: Andreas Plesch <andreasplesch at gmail.com>
>>> >
>>> > >> > Cc: X3D Graphics public mailing list <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.gmail.com
>>> >
>>> > >> > >
>>> >
>>> > >> > 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
>>> >
>>> > >> > <andreasplesch at gmail.com>
>>> >
>>> > >> > wrote:
>>> >
>>> > >> >
>>> >
>>> > >> > > A quick update:
>>> >
>>> > >> > >
>>> >
>>> > >> > > On Tue, Oct 31, 2023 at 3:49?PM Andreas Plesch
>>> >
>>> > >> > > <andreasplesch at gmail.com>
>>> >
>>> > >> > > wrote:
>>> >
>>> > >> > > >
>>> >
>>> > >> > > > Notes:
>>> >
>>> > >> > > >
>>> >
>>> > >> > > > x3d.py is autogenerated from X3DUOM:
>>> >
>>> > >> > > >
>>> >
>>> > >> > > >
>>> https://www.web3d.org/x3d/stylesheets/python/python.html#autoge
>>> >
>>> > >> > > > neration
>>> >
>>> > >> > > >
>>> >
>>> > >> > >
>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>> >
>>> > >> > > Fsourceforge.net%2Fp%2Fx3d%2Fcode%2FHEAD%2Ftree%2Fwww.web3d.org
>>> %2
>>> >
>>> > >> > >
>>> Fx3d%2Fstylesheets%2FX3duomToX3dPythonPackage.xslt&data=05%7C01%7
>>> >
>>> > >> > > Cbrutzman%40nps.edu
>>> %7Ccd2d5f56ffc7496e3e5b08dbdb11f7fb%7C6d936231
>>> >
>>> > >> > >
>>> a51740ea9199f7578963378e%7C0%7C0%7C638344642474548323%7CUnknown%7
>>> >
>>> > >> > >
>>> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
>>> >
>>> > >> > >
>>> LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vUoJQilvuatDOWApbTvcwvEprn8i
>>> >
>>> > >> > > 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%3A%2F%2
>>> >
>>> > >> > >
>>> Fgithub.com%2Fandreasplesch%2Fx3d-python-mod%2Fblob%2Fmain%2Fsrc%
>>> >
>>> > >> > > 2FcfXML.awk&data=05%7C01%7Cbrutzman%40nps.edu
>>> %7Ccd2d5f56ffc7496e3
>>> >
>>> > >> > >
>>> e5b08dbdb11f7fb%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C6383
>>> >
>>> > >> > >
>>> 44642474548323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
>>> >
>>> > >> > >
>>> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=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%3A%2F%2
>>> >
>>> > >> > > Fraw.githubusercontent.com
>>> %2Fandreasplesch%2Fx3d-python-mod%2Fmai
>>> >
>>> > >> > > n%2Fx3dcf.py&data=05%7C01%7Cbrutzman%40nps.edu
>>> %7Ccd2d5f56ffc7496e
>>> >
>>> > >> > >
>>> 3e5b08dbdb11f7fb%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638
>>> >
>>> > >> > >
>>> 344642474704621%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
>>> >
>>> > >> > >
>>> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=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
>>> >
>>> > >> > x3d-public at 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
>>> >
>>> > x3d-public at web3d.org
>>> >
>>> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>
>>>
>>>
>>> --
>>> Andreas Plesch
>>> Waltham, MA 02453
>>>
>>> _______________________________________________
>>> x3d-public mailing list
>>> x3d-public at web3d.org
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>
>> _______________________________________________
> 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/20231102/fc514703/attachment-0001.html>