[x3d-public] x3d.py roundtrip for Metadata nodes in v.3.3 and v.4.0
GPU Group
gpugroup at gmail.com
Thu Nov 2 07:04:59 PDT 2023
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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20231102/345b4c96/attachment-0001.html>
More information about the x3d-public
mailing list