[x3d-public] x3d.py roundtrip for Metadata nodes in v.3.3 and v.4.0
John Carlson
yottzumm at gmail.com
Sat Nov 4 07:42:38 PDT 2023
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.
Perhaps the children field could be added to HAnimHumanoid?
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/components/hanim.html#HAnimHumanoid
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.
I guess originally x3d.py was targeted at the web/jupyter.
John
On Fri, Nov 3, 2023 at 9:45 PM Andreas Plesch <andreasplesch at gmail.com>
wrote:
> On Thu, Nov 2, 2023 at 7:48 PM GPU Group <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 <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
>
>
>
> --
> 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/20231104/0317a5a2/attachment-0001.html>
More information about the x3d-public
mailing list