<div dir="auto">I don’t know the standard, but I believe I had issues trying to view the HAnimHumanoid.children field in VRML/view3dscene, which is why I went with joints, skin, skeleton, etc. instead of children.</div><div dir="auto"><br></div><div dir="auto">Perhaps the children field could be added to HAnimHumanoid?</div><div dir="auto"><br></div><div dir="auto"><div><a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/components/hanim.html#HAnimHumanoid">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/components/hanim.html#HAnimHumanoid</a></div><br></div><div dir="auto">Ultimately we will have XML - python - XML in Blender. I’m not sure if we can accomplish it with x3d.py, but I’d like to try.</div><div dir="auto"><br></div><div dir="auto">I guess originally x3d.py was targeted at the web/jupyter.</div><div dir="auto"><br></div><div dir="auto">John </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 3, 2023 at 9:45 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">On Thu, Nov 2, 2023 at 7:48 PM GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>> wrote:<br>
><br>
> Proposed solution: MFStatement field type in x3d.py<br>
> - each executionContext type ProtoDeclare, Inline, Scene would have 2 new fields<br>
> MFStatement ProtoDeclares<br>
> MFStatement Routes<br>
<br>
Although at first it seems incongruent to have fields with statement<br>
type values, it is not really different from say a color type. So I<br>
think that makes sense.<br>
Should then Shape also have an MFStatement Routes field ? In fact,<br>
since Routes can occur wherever fields occur, all nodes would need<br>
such a field, since all nodes have fields.<br>
<br>
> - then when exporting a scene via x3d.py, protodeclares and routes would be put in those fields<br>
> - x3d.py when writing an execution context to a file would put protodeclares at the top and routes at the bottom.<br>
<br>
I also seem to remember that Don had discussed putting Routes in the<br>
children parameter for x3d.py earlier, as something which is mostly<br>
sufficient. The generated XML/VRML is still valid, there is only an<br>
issue if there is an appetite for complete equivalence between all<br>
encodings, eg. complete roundtrips xml - python - xml.<br>
<br>
containerField support in x3d.py is really unrelated and can be<br>
accomplished in any case.<br>
<br>
-Andreas<br>
<br>
><br>
> On Thu, Nov 2, 2023 at 7:42 AM GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>> wrote:<br>
>><br>
>> 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.<br>
>> -Doug<br>
>><br>
>><br>
>> On Wed, Nov 1, 2023 at 8:54 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi Don,<br>
>>><br>
>>> All true and relevant, of course. I think the important phrase is<br>
>>> "inside a node wherever fields may appear". The question becomes what<br>
>>> does that phrase mean for the python encoding ? It is unclear that it<br>
>>> means ROUTE statements should appear as members of the array which is<br>
>>> assigned to the children field of a node, or any other MFNode field of<br>
>>> a node. The python encoding does not currently allow for non-field<br>
>>> parameters to appear inside a X3D node, eg. inside the parameters<br>
>>> given to the node returning function call. So, as a consequence, the<br>
>>> only option currently is to add ROUTE statements to MFNode field<br>
>>> values in the python encoding which to me seems more like a band aid.<br>
>>> For example, it seems to make it impossible to represent a ROUTE<br>
>>> inside a node which only has SFNode fields like:<br>
>>><br>
>>> XML:<br>
>>> <Shape><br>
>>> <Appearance><br>
>>> <Material DEF='boxColor' diffuseColor='1 0 0' /><br>
>>> </Appearance><br>
>>> <ROUTE fromNode='cIntrpltr' fromField='value_changed'<br>
>>> toNode='boxColor' toField='diffuseColor' /><br>
>>> <Box/><br>
>>> </Shape><br>
>>><br>
>>> Python:<br>
>>> Shape(<br>
>>> appearance=Appearance(<br>
>>> material=Material(DEF='boxColor', diffuseColor=SFColor(1,0,0))),<br>
>>> # How to add a ROUTE here ?<br>
>>> # children=[ ROUTE(..) ] ?<br>
>>> geometry=Box()<br>
>>> )<br>
>>><br>
>>> Perhaps the children parameter is allowed for any node in the Python encoding ?<br>
>>><br>
>>> Would it make sense to add a 'statements' parameter or an 'inside'<br>
>>> parameter to node generating functions in python ? Possibly too late<br>
>>> for that.<br>
>>><br>
>>> In any case, for containerField support it is possible to just have<br>
>>> Route.XML() (and Comment.XML()) accept an optional field parameter<br>
>>> which is ignored.<br>
>>><br>
>>> -Andreas<br>
>>><br>
>>> On Wed, Nov 1, 2023 at 8:03 PM Brutzman, Donald (Don) (CIV)<br>
>>> <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br>
>>> ><br>
>>> > Checking details: placement of ROUTE (and several other X3D statements) is allowed as a child of X3DGroupingNode and is permitted by XML validation.<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > 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.<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > 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.<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > 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.<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > X3D 4.0 Architecture, clause 4 Concepts, 4.4.2.4.1 Routes<br>
>>> > <a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/concepts.html#ModifyingObjectsRoutes" rel="noreferrer" target="_blank">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/concepts.html#ModifyingObjectsRoutes</a><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > EXAMPLE It is possible to create a scene with run-time behavior using only this event propagation model:<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > DEF TS TimeSensor {<br>
>>> ><br>
>>> > loop TRUE<br>
>>> ><br>
>>> > cycleInterval 5<br>
>>> ><br>
>>> > }<br>
>>> ><br>
>>> > DEF I PositionInterpolator {<br>
>>> ><br>
>>> > key [ 0 0.5 1 ]<br>
>>> ><br>
>>> > keyValue [ 0 -1 0, 0 1 0, 0 -1 0 ]<br>
>>> ><br>
>>> > }<br>
>>> ><br>
>>> > DEF T Transform {<br>
>>> ><br>
>>> > children [<br>
>>> ><br>
>>> > Shape {<br>
>>> ><br>
>>> > geometry Box { }<br>
>>> ><br>
>>> > }<br>
>>> ><br>
>>> > ]<br>
>>> ><br>
>>> > }<br>
>>> ><br>
>>> > ROUTE ts.fraction_changed TO I.set_fraction<br>
>>> ><br>
>>> > ROUTE I.value_changed TO T.set_translation<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > Also relevant:<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > X3D 4.0 Architecture, clause 4 Concepts, 4.4.8.2 Routes<br>
>>> > <a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/concepts.html#Routes" rel="noreferrer" target="_blank">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/concepts.html#Routes</a><br>
>>> > 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.”<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > Hope this makes sense. Thanks everyone for paying close attention… validatable correctness is essential.<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > Have fun with X3D! 8)<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > all the best, Don<br>
>>> ><br>
>>> > --<br>
>>> ><br>
>>> > Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
>>> ><br>
>>> > Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<br>
>>> ><br>
>>> > X3D graphics, virtual worlds, navy robotics <a href="https://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">https://faculty.nps.edu/brutzman</a><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > -----Original Message-----<br>
>>> > From: x3d-public <<a href="mailto:x3d-public-bounces@web3d.org" target="_blank">x3d-public-bounces@web3d.org</a>> On Behalf Of Andreas Plesch<br>
>>> > Sent: Wednesday, November 1, 2023 12:36 PM<br>
>>> > To: John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>><br>
>>> > Cc: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
>>> > Subject: Re: [x3d-public] x3d.py roundtrip for Metadata nodes in v.3.3 and v.4.0<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > 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.<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > 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.<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > -Andreas<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > On Wed, Nov 1, 2023 at 1:35 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
>>> ><br>
>>> > ><br>
>>> ><br>
>>> > > First "bug" report:<br>
>>> ><br>
>>> > ><br>
>>> ><br>
>>> > > $ py JoeKick.py<br>
>>> ><br>
>>> > > x3d.py package 4.0.64.4 loaded, have fun with X3D Graphics!<br>
>>> ><br>
>>> > > Self-test diagnostics for JoeKick.py:<br>
>>> ><br>
>>> > > meta information, TODO: Record information about skin coordinates<br>
>>> ><br>
>>> > > (found in comment at end of scene) as a structured MetadataSet containing MetadataString nodes Traceback (most recent call last):<br>
>>> ><br>
>>> > > File "C:\Users\john\X3DJSONLD\blend\JoeKick.py", line 715, in <module><br>
>>> ><br>
>>> > > newModelXML= newModel.XML() # test export method XML() for exceptions during export<br>
>>> ><br>
>>> > > ^^^^^^^^^^^^^^<br>
>>> ><br>
>>> > > File "C:\Users\john\x3d-python-mod\x3dcf.py", line 14985, in XML<br>
>>> ><br>
>>> > > result += str(self.Scene.XML(indentLevel=indentLevel+1, syntax=syntax))<br>
>>> ><br>
>>> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
>>> ><br>
>>> > > File "C:\Users\john\x3d-python-mod\x3dcf.py", line 14494, in XML<br>
>>> ><br>
>>> > > result += each.XML(indentLevel=indentLevel+1, syntax=syntax)<br>
>>> ><br>
>>> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
>>> ><br>
>>> > > File "C:\Users\john\x3d-python-mod\x3dcf.py", line 45024, in XML<br>
>>> ><br>
>>> > > result += each.XML(indentLevel=indentLevel+1, syntax=syntax, field="children")<br>
>>> ><br>
>>> > ><br>
>>> ><br>
>>> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
>>> ><br>
>>> > > TypeError: ROUTE.XML() got an unexpected keyword argument 'field'<br>
>>> ><br>
>>> > ><br>
>>> ><br>
>>> > > I have to take a half hour off volunteering, I hope to be back soon.<br>
>>> ><br>
>>> > ><br>
>>> ><br>
>>> > > John<br>
>>> ><br>
>>> > ><br>
>>> ><br>
>>> > > On Wed, Nov 1, 2023 at 12:22 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>>> ><br>
>>> > >><br>
>>> ><br>
>>> > >> Thanks for giving this a try ! Glad to hear it could be useful,<br>
>>> ><br>
>>> > >><br>
>>> ><br>
>>> > >> Andreas<br>
>>> ><br>
>>> > >><br>
>>> ><br>
>>> > >> > Message: 2<br>
>>> ><br>
>>> > >> > Date: Wed, 1 Nov 2023 11:16:24 -0400<br>
>>> ><br>
>>> > >> > From: Vincent Marchetti <<a href="mailto:vmarchetti@kshell.com" target="_blank">vmarchetti@kshell.com</a>><br>
>>> ><br>
>>> > >> > To: X3D-Public <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
>>> ><br>
>>> > >> > Subject: Re: [x3d-public] x3d.py roundtrip for Metadata nodes in v.3.3<br>
>>> ><br>
>>> > >> > and v.4.0<br>
>>> ><br>
>>> > >> > Message-ID: <<a href="mailto:38B8549E-944D-460F-B5D7-31BC73721015@kshell.com" target="_blank">38B8549E-944D-460F-B5D7-31BC73721015@kshell.com</a>><br>
>>> ><br>
>>> > >> > Content-Type: text/plain; charset="us-ascii"<br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> > 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.<br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> > 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.<br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> > The pertinent accurate encoding is:<br>
>>> ><br>
>>> > >> > ------<br>
>>> ><br>
>>> > >> > <WorldInfo><br>
>>> ><br>
>>> > >> > <MetadataSet containerField='metadata' name='birthday' reference='<a href="https://www.archives.gov/legislative/features/washington" rel="noreferrer" target="_blank">https://www.archives.gov/legislative/features/washington</a>'><br>
>>> ><br>
>>> > >> > <MetadataString containerField='metadata' name='calendar' value='"Julian"'/><br>
>>> ><br>
>>> > >> > <MetadataInteger containerField='value' name='day' value='11'/><br>
>>> ><br>
>>> > >> > <MetadataInteger containerField='value' name='month' value='2'/><br>
>>> ><br>
>>> > >> > <MetadataInteger containerField='value' name='year' value='1731'/><br>
>>> ><br>
>>> > >> > </MetadataSet><br>
>>> ><br>
>>> > >> > </WorldInfo><br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> > -----<br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> > Vince Marchetti<br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> > -------------- next part -------------- A non-text attachment was<br>
>>> ><br>
>>> > >> > scrubbed...<br>
>>> ><br>
>>> > >> > Name: GenerateCalendarMetadataWithCF.py<br>
>>> ><br>
>>> > >> > Type: text/x-python-script<br>
>>> ><br>
>>> > >> > Size: 791 bytes<br>
>>> ><br>
>>> > >> > Desc: not available<br>
>>> ><br>
>>> > >> > URL:<br>
>>> ><br>
>>> > >> > <<a href="http://web3d.org/pipermail/x3d-public_web3d.org/attachments/202311" rel="noreferrer" target="_blank">http://web3d.org/pipermail/x3d-public_web3d.org/attachments/202311</a><br>
>>> ><br>
>>> > >> > 01/1383c745/attachment-0001.bin><br>
>>> ><br>
>>> > >> > -------------- next part -------------- A non-text attachment was<br>
>>> ><br>
>>> > >> > scrubbed...<br>
>>> ><br>
>>> > >> > Name: GeneratedCalendarMetadataWithCF.x3d<br>
>>> ><br>
>>> > >> > Type: model/x3d+xml<br>
>>> ><br>
>>> > >> > Size: 920 bytes<br>
>>> ><br>
>>> > >> > Desc: not available<br>
>>> ><br>
>>> > >> > URL:<br>
>>> ><br>
>>> > >> > <<a href="http://web3d.org/pipermail/x3d-public_web3d.org/attachments/202311" rel="noreferrer" target="_blank">http://web3d.org/pipermail/x3d-public_web3d.org/attachments/202311</a><br>
>>> ><br>
>>> > >> > 01/1383c745/attachment-0001.x3d><br>
>>> ><br>
>>> > >> > -------------- next part --------------<br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> > > On Nov 1, 2023, at 10:23 AM, Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>>> ><br>
>>> > >> > ><br>
>>> ><br>
>>> > >> > > A quick update:<br>
>>> ><br>
>>> > >> > ><br>
>>> ><br>
>>> > >> > > On Tue, Oct 31, 2023 at 3:49?PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>>> ><br>
>>> > >> > >><br>
>>> ><br>
>>> > >> > >> Notes:<br>
>>> ><br>
>>> > >> > >><br>
>>> ><br>
>>> > >> > >> x3d.py is autogenerated from X3DUOM:<br>
>>> ><br>
>>> > >> > >><br>
>>> ><br>
>>> > >> > >> <a href="https://www.web3d.org/x3d/stylesheets/python/python.html#autogen" rel="noreferrer" target="_blank">https://www.web3d.org/x3d/stylesheets/python/python.html#autogen</a><br>
>>> ><br>
>>> > >> > >> eration<br>
>>> ><br>
>>> > >> > >> <a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%" rel="noreferrer" target="_blank">https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%</a><br>
>>> ><br>
>>> > >> > >> 2Fsourceforge.net%2Fp%2Fx3d%2Fcode%2FHEAD%2Ftree%<a href="http://2Fwww.web3d.org" rel="noreferrer" target="_blank">2Fwww.web3d.org</a><br>
>>> ><br>
>>> > >> > >> %2Fx3d%2Fstylesheets%2FX3duomToX3dPythonPackage.xslt&data=05%7C0<br>
>>> ><br>
>>> > >> > >> 1%7Cbrutzman%<a href="http://40nps.edu" rel="noreferrer" target="_blank">40nps.edu</a>%7Ccd2d5f56ffc7496e3e5b08dbdb11f7fb%7C6d93<br>
>>> ><br>
>>> > >> > >> 6231a51740ea9199f7578963378e%7C0%7C0%7C638344642474548323%7CUnkn<br>
>>> ><br>
>>> > >> > >> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik<br>
>>> ><br>
>>> > >> > >> 1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vUoJQilvuatDOWApbTvcw<br>
>>> ><br>
>>> > >> > >> vEprn8iyCs%2B%2F%2F7xTlQxpYE%3D&reserved=0<br>
>>> ><br>
>>> > >> > >><br>
>>> ><br>
>>> > >> > >> X3DUOM has all necessary containerField default value information.<br>
>>> ><br>
>>> > >> > >><br>
>>> ><br>
>>> > >> > >> But the first step may be to modify the stylesheet to generate<br>
>>> ><br>
>>> > >> > >> containerField attributes for all nodes, for simplicity. It<br>
>>> ><br>
>>> > >> > >> looks like the .XML() function would have to have an additional parameter 'field'<br>
>>> ><br>
>>> > >> > >> X3D(indentLevel, syntax, field) for each node.<br>
>>> ><br>
>>> > >> > >><br>
>>> ><br>
>>> > >> > >> Postprocessing the generated XML is not possible since<br>
>>> ><br>
>>> > >> > >> information was irretrievably lost. But postprocessing the<br>
>>> ><br>
>>> > >> > >> autogenerated x3d.py python code may be possible since xslt is not for everyone.<br>
>>> ><br>
>>> > >> > ><br>
>>> ><br>
>>> > >> > > As a proof of concept I hacked a short awk (since I know it)<br>
>>> ><br>
>>> > >> > > script to process the latest x3d.py to include containerField support:<br>
>>> ><br>
>>> > >> > ><br>
>>> ><br>
>>> > >> > > <a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2" rel="noreferrer" target="_blank">https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2</a><br>
>>> ><br>
>>> > >> > > Fgithub.com%2Fandreasplesch%2Fx3d-python-mod%2Fblob%2Fmain%2Fsrc%<br>
>>> ><br>
>>> > >> > > 2FcfXML.awk&data=05%7C01%7Cbrutzman%<a href="http://40nps.edu" rel="noreferrer" target="_blank">40nps.edu</a>%7Ccd2d5f56ffc7496e3<br>
>>> ><br>
>>> > >> > > e5b08dbdb11f7fb%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C6383<br>
>>> ><br>
>>> > >> > > 44642474548323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj<br>
>>> ><br>
>>> > >> > > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6X<br>
>>> ><br>
>>> > >> > > xOQrg8Id5BdOwqnW52BBFwDkmMPwhgKsa2BLle6ms%3D&reserved=0<br>
>>> ><br>
>>> > >> > ><br>
>>> ><br>
>>> > >> > > It looks for the Concrete Nodes section, adds a field parameter<br>
>>> ><br>
>>> > >> > > to the<br>
>>> ><br>
>>> > >> > > .XML() output function, adds the containerField attribute to the<br>
>>> ><br>
>>> > >> > > output, and adds the field parameter to the .XML() calls for<br>
>>> ><br>
>>> > >> > > metadata, SFNode and MFNode field processing.<br>
>>> ><br>
>>> > >> > > The awk script is very brittle since it relies on comments in<br>
>>> ><br>
>>> > >> > > x3d.py to find the appropriate lines to modify. The hardest part<br>
>>> ><br>
>>> > >> > > was to get the quoting and escaping correct.<br>
>>> ><br>
>>> > >> > > It generates containerField attributes for all SF/MFNode fields<br>
>>> ><br>
>>> > >> > > except 'children'. Of course, most are unnecessary but filtering<br>
>>> ><br>
>>> > >> > > systematically for defaults would probably require involving<br>
>>> ><br>
>>> > >> > > X3DUOM and the generation stylesheet, similar to other XML related 'fields'<br>
>>> ><br>
>>> > >> > > such as style or class.<br>
>>> ><br>
>>> > >> > ><br>
>>> ><br>
>>> > >> > > The result is<br>
>>> ><br>
>>> > >> > > <a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2" rel="noreferrer" target="_blank">https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2</a><br>
>>> ><br>
>>> > >> > > <a href="http://Fraw.githubusercontent.com" rel="noreferrer" target="_blank">Fraw.githubusercontent.com</a>%2Fandreasplesch%2Fx3d-python-mod%2Fmai<br>
>>> ><br>
>>> > >> > > n%2Fx3dcf.py&data=05%7C01%7Cbrutzman%<a href="http://40nps.edu" rel="noreferrer" target="_blank">40nps.edu</a>%7Ccd2d5f56ffc7496e<br>
>>> ><br>
>>> > >> > > 3e5b08dbdb11f7fb%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638<br>
>>> ><br>
>>> > >> > > 344642474548323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI<br>
>>> ><br>
>>> > >> > > joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=p<br>
>>> ><br>
>>> > >> > > Lm5kiuYmgbb5jcjp09KTCrIzUt2p%2BkdYlrjyYpkhac%3D&reserved=0<br>
>>> ><br>
>>> > >> > ><br>
>>> ><br>
>>> > >> > > The modified python script appears to work as expected by adding<br>
>>> ><br>
>>> > >> > > the appropriate containerField attributes in XML output for all<br>
>>> ><br>
>>> > >> > > the examples I tried.<br>
>>> ><br>
>>> > >> > > Realistically, this is as far as I can go with this but I think<br>
>>> ><br>
>>> > >> > > it may show how containerField support in XML output could be<br>
>>> ><br>
>>> > >> > > provided with x3d.py.<br>
>>> ><br>
>>> > >> > ><br>
>>> ><br>
>>> > >> > > -Andreas<br>
>>> ><br>
>>> > >> > ><br>
>>> ><br>
>>> > >> > > _______________________________________________<br>
>>> ><br>
>>> > >> > > x3d-public mailing list<br>
>>> ><br>
>>> > >> > > <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
>>> ><br>
>>> > >> > > <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> > ------------------------------<br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> > Message: 3<br>
>>> ><br>
>>> > >> > Date: Wed, 1 Nov 2023 11:05:29 -0500<br>
>>> ><br>
>>> > >> > From: John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>><br>
>>> ><br>
>>> > >> > To: Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>><br>
>>> ><br>
>>> > >> > Cc: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
>>> ><br>
>>> > >> > Subject: Re: [x3d-public] x3d.py roundtrip for Metadata nodes in v.3.3<br>
>>> ><br>
>>> > >> > and v.4.0<br>
>>> ><br>
>>> > >> > Message-ID:<br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> > <CAGC3UEkYxP0tk5rQ23VVhsd0gXW7W+AH5QaS=<a href="mailto:AWxkv0f8kgo1Q@mail.gmail.com" target="_blank">AWxkv0f8kgo1Q@mail.gmail.com</a><br>
>>> ><br>
>>> > >> > ><br>
>>> ><br>
>>> > >> > Content-Type: text/plain; charset="utf-8"<br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> > You are awesome, Andreas! Awk would not have been my choice, but<br>
>>> ><br>
>>> > >> > apparently, you made it work! Perhaps I will make a Perl script based on<br>
>>> ><br>
>>> > >> > your awk. A python script could be written to process X3DUOM and probably<br>
>>> ><br>
>>> > >> > do the matching as well.<br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> > Dang cool!<br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> > On Wed, Nov 1, 2023 at 9:24 AM Andreas Plesch<br>
>>> ><br>
>>> > >> > <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>><br>
>>> ><br>
>>> > >> > wrote:<br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> > > A quick update:<br>
>>> ><br>
>>> > >> > ><br>
>>> ><br>
>>> > >> > > On Tue, Oct 31, 2023 at 3:49?PM Andreas Plesch<br>
>>> ><br>
>>> > >> > > <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>><br>
>>> ><br>
>>> > >> > > wrote:<br>
>>> ><br>
>>> > >> > > ><br>
>>> ><br>
>>> > >> > > > Notes:<br>
>>> ><br>
>>> > >> > > ><br>
>>> ><br>
>>> > >> > > > x3d.py is autogenerated from X3DUOM:<br>
>>> ><br>
>>> > >> > > ><br>
>>> ><br>
>>> > >> > > > <a href="https://www.web3d.org/x3d/stylesheets/python/python.html#autoge" rel="noreferrer" target="_blank">https://www.web3d.org/x3d/stylesheets/python/python.html#autoge</a><br>
>>> ><br>
>>> > >> > > > neration<br>
>>> ><br>
>>> > >> > > ><br>
>>> ><br>
>>> > >> > > <a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2" rel="noreferrer" target="_blank">https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2</a><br>
>>> ><br>
>>> > >> > > Fsourceforge.net%2Fp%2Fx3d%2Fcode%2FHEAD%2Ftree%<a href="http://2Fwww.web3d.org" rel="noreferrer" target="_blank">2Fwww.web3d.org</a>%2<br>
>>> ><br>
>>> > >> > > Fx3d%2Fstylesheets%2FX3duomToX3dPythonPackage.xslt&data=05%7C01%7<br>
>>> ><br>
>>> > >> > > Cbrutzman%<a href="http://40nps.edu" rel="noreferrer" target="_blank">40nps.edu</a>%7Ccd2d5f56ffc7496e3e5b08dbdb11f7fb%7C6d936231<br>
>>> ><br>
>>> > >> > > a51740ea9199f7578963378e%7C0%7C0%7C638344642474548323%7CUnknown%7<br>
>>> ><br>
>>> > >> > > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi<br>
>>> ><br>
>>> > >> > > LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vUoJQilvuatDOWApbTvcwvEprn8i<br>
>>> ><br>
>>> > >> > > yCs%2B%2F%2F7xTlQxpYE%3D&reserved=0<br>
>>> ><br>
>>> > >> > > ><br>
>>> ><br>
>>> > >> > > > X3DUOM has all necessary containerField default value information.<br>
>>> ><br>
>>> > >> > > ><br>
>>> ><br>
>>> > >> > > > But the first step may be to modify the stylesheet to generate<br>
>>> ><br>
>>> > >> > > > containerField attributes for all nodes, for simplicity. It<br>
>>> ><br>
>>> > >> > > > looks like the .XML() function would have to have an additional parameter 'field'<br>
>>> ><br>
>>> > >> > > > X3D(indentLevel, syntax, field) for each node.<br>
>>> ><br>
>>> > >> > > ><br>
>>> ><br>
>>> > >> > > > Postprocessing the generated XML is not possible since<br>
>>> ><br>
>>> > >> > > > information was irretrievably lost. But postprocessing the<br>
>>> ><br>
>>> > >> > > > autogenerated x3d.py python code may be possible since xslt is not for everyone.<br>
>>> ><br>
>>> > >> > ><br>
>>> ><br>
>>> > >> > > As a proof of concept I hacked a short awk (since I know it)<br>
>>> ><br>
>>> > >> > > script to process the latest x3d.py to include containerField support:<br>
>>> ><br>
>>> > >> > ><br>
>>> ><br>
>>> > >> > > <a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2" rel="noreferrer" target="_blank">https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2</a><br>
>>> ><br>
>>> > >> > > Fgithub.com%2Fandreasplesch%2Fx3d-python-mod%2Fblob%2Fmain%2Fsrc%<br>
>>> ><br>
>>> > >> > > 2FcfXML.awk&data=05%7C01%7Cbrutzman%<a href="http://40nps.edu" rel="noreferrer" target="_blank">40nps.edu</a>%7Ccd2d5f56ffc7496e3<br>
>>> ><br>
>>> > >> > > e5b08dbdb11f7fb%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C6383<br>
>>> ><br>
>>> > >> > > 44642474548323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj<br>
>>> ><br>
>>> > >> > > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6X<br>
>>> ><br>
>>> > >> > > xOQrg8Id5BdOwqnW52BBFwDkmMPwhgKsa2BLle6ms%3D&reserved=0<br>
>>> ><br>
>>> > >> > ><br>
>>> ><br>
>>> > >> > > It looks for the Concrete Nodes section, adds a field parameter<br>
>>> ><br>
>>> > >> > > to the<br>
>>> ><br>
>>> > >> > > .XML() output function, adds the containerField attribute to the<br>
>>> ><br>
>>> > >> > > output, and adds the field parameter to the .XML() calls for<br>
>>> ><br>
>>> > >> > > metadata, SFNode and MFNode field processing.<br>
>>> ><br>
>>> > >> > > The awk script is very brittle since it relies on comments in<br>
>>> ><br>
>>> > >> > > x3d.py to find the appropriate lines to modify. The hardest part<br>
>>> ><br>
>>> > >> > > was to get the quoting and escaping correct.<br>
>>> ><br>
>>> > >> > > It generates containerField attributes for all SF/MFNode fields<br>
>>> ><br>
>>> > >> > > except 'children'. Of course, most are unnecessary but filtering<br>
>>> ><br>
>>> > >> > > systematically for defaults would probably require involving<br>
>>> ><br>
>>> > >> > > X3DUOM and the generation stylesheet, similar to other XML related 'fields'<br>
>>> ><br>
>>> > >> > > such as style or class.<br>
>>> ><br>
>>> > >> > ><br>
>>> ><br>
>>> > >> > > The result is<br>
>>> ><br>
>>> > >> > > <a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2" rel="noreferrer" target="_blank">https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2</a><br>
>>> ><br>
>>> > >> > > <a href="http://Fraw.githubusercontent.com" rel="noreferrer" target="_blank">Fraw.githubusercontent.com</a>%2Fandreasplesch%2Fx3d-python-mod%2Fmai<br>
>>> ><br>
>>> > >> > > n%2Fx3dcf.py&data=05%7C01%7Cbrutzman%<a href="http://40nps.edu" rel="noreferrer" target="_blank">40nps.edu</a>%7Ccd2d5f56ffc7496e<br>
>>> ><br>
>>> > >> > > 3e5b08dbdb11f7fb%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638<br>
>>> ><br>
>>> > >> > > 344642474704621%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI<br>
>>> ><br>
>>> > >> > > joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7<br>
>>> ><br>
>>> > >> > > 4nwRmIni6cSY%2FMdNtOH5VNh9l6%2FScsR4te6XOlwKug%3D&reserved=0<br>
>>> ><br>
>>> > >> > ><br>
>>> ><br>
>>> > >> > > The modified python script appears to work as expected by adding<br>
>>> ><br>
>>> > >> > > the appropriate containerField attributes in XML output for all<br>
>>> ><br>
>>> > >> > > the examples I tried.<br>
>>> ><br>
>>> > >> > > Realistically, this is as far as I can go with this but I think<br>
>>> ><br>
>>> > >> > > it may show how containerField support in XML output could be<br>
>>> ><br>
>>> > >> > > provided with x3d.py.<br>
>>> ><br>
>>> > >> > ><br>
>>> ><br>
>>> > >> > > -Andreas<br>
>>> ><br>
>>> > >> > ><br>
>>> ><br>
>>> > >> > -------------- next part -------------- An HTML attachment was<br>
>>> ><br>
>>> > >> > scrubbed...<br>
>>> ><br>
>>> > >> > URL:<br>
>>> ><br>
>>> > >> > <<a href="http://web3d.org/pipermail/x3d-public_web3d.org/attachments/202311" rel="noreferrer" target="_blank">http://web3d.org/pipermail/x3d-public_web3d.org/attachments/202311</a><br>
>>> ><br>
>>> > >> > 01/59b1f34d/attachment.html><br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> > ------------------------------<br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> > Subject: Digest Footer<br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> > _______________________________________________<br>
>>> ><br>
>>> > >> > x3d-public mailing list<br>
>>> ><br>
>>> > >> > <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
>>> ><br>
>>> > >> > <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> > ------------------------------<br>
>>> ><br>
>>> > >> ><br>
>>> ><br>
>>> > >> > End of x3d-public Digest, Vol 176, Issue 4<br>
>>> ><br>
>>> > >> > ******************************************<br>
>>> ><br>
>>> > >><br>
>>> ><br>
>>> > >><br>
>>> ><br>
>>> > >><br>
>>> ><br>
>>> > >> --<br>
>>> ><br>
>>> > >> Andreas Plesch<br>
>>> ><br>
>>> > >> Waltham, MA 02453<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > --<br>
>>> ><br>
>>> > Andreas Plesch<br>
>>> ><br>
>>> > Waltham, MA 02453<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > _______________________________________________<br>
>>> ><br>
>>> > x3d-public mailing list<br>
>>> ><br>
>>> > <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
>>> ><br>
>>> > <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Andreas Plesch<br>
>>> Waltham, MA 02453<br>
>>><br>
>>> _______________________________________________<br>
>>> x3d-public mailing list<br>
>>> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
>>> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
<br>
<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div></div>