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

Wed Nov 1 14:30:39 PDT 2023

I haven't seen any ROUTE issues in the latest release.

Great effort!

John

On Wed, Nov 1, 2023 at 2:36 PM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> 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/20231101/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/20231101/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#autogeneration
> >> > >>
> https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/X3duomToX3dPythonPackage.xslt
> >> > >>
> >> > >> 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://github.com/andreasplesch/x3d-python-mod/blob/main/src/cfXML.awk
> >> > >
> >> > > 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://raw.githubusercontent.com/andreasplesch/x3d-python-mod/main/x3dcf.py
> >> > >
> >> > > 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#autogeneration
> >> > > >
> >> > >
> https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/X3duomToX3dPythonPackage.xslt
> >> > > >
> >> > > > 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://github.com/andreasplesch/x3d-python-mod/blob/main/src/cfXML.awk
> >> > >
> >> > > 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://raw.githubusercontent.com/andreasplesch/x3d-python-mod/main/x3dcf.py
> >> > >
> >> > > 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/20231101/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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20231101/0eda5382/attachment-0001.html>