<div dir="auto">This might be possible with a good python parser/generator, but we’d have to maintain that as well, so probably no-go.</div><div dir="auto"><br></div><div dir="auto">I think the best bet for people who dislike xslt may be to convert all the xslt to saxon api usage, or alternatively redo everything with the help of that which must not be named, as recommended by my college friend at Amazon who won’t touch xslt. Xslt is fairly stable though, probably more stable than a saxon api. Would one rather maintain a lot of xslt, a lot of saxon code, or something different? I can barely maintain my serializers, but they work with DOM; I feel a lot more comfortable with DOM than XSLT, but getting familiar with XSLT tools beyond a text editor may be worth it.</div><div dir="auto"><br></div><div dir="auto">Perhaps we could get C/C++ people interested with a different Saxon API?</div><div dir="auto"><br></div><div dir="auto">Maybe we should move from XML to some kind of OpenUSD?</div><div dir="auto"><br></div><div dir="auto">I think X3DUOM v4 may already be JSON.</div><div dir="auto"><br></div><div dir="auto">John</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 31, 2023 at 2:50 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)" dir="auto">Notes:<br>
<br>Postprocessing the generated XML is not possible since information was<br>
irretrievably lost. But postprocessing the autogenerated x3d.py python<br>
code may be possible since xslt is not for everyone.<br>
<br>
-Andreas<br>
<br>
<br>
<br>
On Tue, Oct 31, 2023 at 2:10 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
><br>
> Thank you Andreas for bringing this up. x3d.py as of last night, did not output any containerFields.<br>
><br>
> I don’t think that putting containerFields everywhere is the right solution. It would be great if x3d.py could figure out what containerField field to use, like for HAnimHumanoid's skeleton, skin fields, and joints/segments/sites fields. Right now, x3d.py prevents the user from specifying any containerFields, because x3d.py controls pretty much all output. My idea was to pass an optional containerField to an XML method, but since ix3d.py is created with a stylesheet, this will affect many XML methods potentially, so this will need to be controlled carefully.<br>
><br>
> I have a lot of related experience trying to get containerField right for X3DJSONLD/X3DJSAIL when creating DOM from JSON in <a href="https://github.com/coderextreme/x3dschema/blob/main/X3DJSONLD.java" rel="noreferrer" target="_blank">https://github.com/coderextreme/x3dschema/blob/main/X3DJSONLD.java</a>. Here's my current results. More logic probably needs to be added for the skin fields<br>
><br>
> public Element CreateElement(Document document, String key, String containerField) {<br>
> Element child = document.createElement(key);<br>
> if (containerField != null &&<br>
> ((containerField.equals("geometry") && key.equals("IndexedFaceSet")) ||<br>
> (containerField.equals("geometry") && key.equals("Text")) ||<br>
> (containerField.equals("geometry") && key.equals("IndexedTriangleSet")) ||<br>
> (containerField.equals("geometry") && key.equals("Sphere")) ||<br>
> (containerField.equals("geometry") && key.equals("Cylinder")) ||<br>
> (containerField.equals("geometry") && key.equals("Cone")) ||<br>
> (containerField.equals("geometry") && key.equals("LineSet")) ||<br>
> (containerField.equals("geometry") && key.equals("IndexedLineSet")) ||<br>
> (containerField.equals("geometry") && key.equals("Box")) ||<br>
> (containerField.equals("geometry") && key.equals("Extrusion")) ||<br>
> (containerField.equals("geometry") && key.equals("GeoElevationGrid")) ||<br>
> (containerField.equals("shape") && key.equals("Shape")) ||<br>
> (containerField.equals("skin") && key.equals("Shape")) ||<br>
> (containerField.endsWith("exture") && key.equals("ImageTexture")) ||<br>
> (key.equals("HAnimSegment")) ||<br>
> (key.equals("HAnimSite")) ||<br>
> (key.equals("HAnimMotion")) ||<br>
> (containerField.equals("skinCoord") && key.equals("Coordinate")) || // overwrite coord with skinCoord, if set<br>
> (containerField.equals("skin") && key.equals("IndexedFaceSet")) ||<br>
> ((containerField.equals("skinBindingCoords") || containerField.equals("skinCoord")) && key.equals("Coordinate")) ||<br>
> ((containerField.equals("normal") || containerField.equals("skinBindingNormals") || containerField.equals("skinNormal")) && key.equals("Normal")) ||<br>
> ((containerField.equals("skeleton") || containerField.equals("children") || containerField.equals("joints")) && key.equals("HAnimJoint"))<br>
> )) {<br>
> elementSetAttribute(child, "containerField", containerField);<br>
> }<br>
> return child;<br>
> }<br>
><br>
> if ((containerField == null || containerField.equals("children")) && parentkey.equals("HAnimJoint") && element.getTagName().equals("HAnimHumanoid")) {<br>
> containerField = "joints";<br>
> }<br>
> if ((containerField == null || containerField.equals("coord")) && parentkey.equals("Coordinate") && element.getTagName().equals("HAnimHumanoid")) {<br>
> containerField = "skinCoord";<br>
> }<br>
> child = CreateElement(document, parentkey, containerField);<br>
><br>
><br>
> I don't know if something similar could be added for x3d.py or whether x3d.py can be sufficiently tested. I am willing to put in effort to run code output from X3dToPython.xslt in the archive, which I know no one else wants to do. But someone else will have to go through possibly the tons of output from tovrmlx3d that is created. My recommendation is to do onesies-twosies as Don suggested and likes. I will try to set up a testing framework with a modified X3dToPython.xslt. This will take away from my WS work.<br>
><br>
> On Tue, Oct 31, 2023 at 12:21 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>><br>
>> x3d.py may not quite manage a roundtrip back to XML for MetadataSet.<br>
>><br>
>> <a href="https://www.web3d.org/x3d/content/examples/X3dForWebAuthors/Chapter01TechnicalOverview/EmptySceneCoreProfileIndex.html" rel="noreferrer" target="_blank">https://www.web3d.org/x3d/content/examples/X3dForWebAuthors/Chapter01TechnicalOverview/EmptySceneCoreProfileIndex.html</a><br>
>><br>
>> has the model in XML encoding:<br>
>><br>
>> ..<br>
>> <Scene><br>
>> <!-- Core profile can only contain WorldInfo and Metadata nodes. here!!! --><br>
>> <WorldInfo title='EmptySceneCoreProfile.x3d'/><br>
>> <WorldInfo title='EmptySceneCoreProfile.x3d'><br>
>> <MetadataSet name='NodeSet' containerField='metadata'><br>
>> <MetadataBoolean containerField='value' name='BooleanData'<br>
>> value='true false'/><br>
>> <MetadataDouble containerField='value' name='DoubleData' value='1 2 3'/><br>
>> <MetadataFloat containerField='value' name='FloatData' value='4 5 6'/><br>
>> <MetadataInteger containerField='value' name='IntegerData' value='7 8 9'/><br>
>> <MetadataString containerField='value' name='StringData'<br>
>> value='"Empty Scene" "Core Profile"'/><br>
>> </MetadataSet><br>
>> </WorldInfo><br>
>> </Scene><br>
>> ...<br>
>><br>
>> Running <a href="https://www.web3d.org/x3d/content/examples/X3dForWebAuthors/Chapter01TechnicalOverview/EmptySceneCoreProfile.py" rel="noreferrer" target="_blank">https://www.web3d.org/x3d/content/examples/X3dForWebAuthors/Chapter01TechnicalOverview/EmptySceneCoreProfile.py</a><br>
>><br>
>> with the latest x3d.py confirms well formedness of the .XML() output.<br>
>><br>
>> Uncommenting the diagnostic line to print the XML output gives this XML:<br>
>><br>
>> <?xml version="1.0" encoding="UTF-8"?><br>
>> <!DOCTYPE X3D PUBLIC "ISO//Web3D//DTD X3D 3.3//EN"<br>
>> "<a href="https://www.web3d.org/specifications/x3d-3.3.dtd" rel="noreferrer" target="_blank">https://www.web3d.org/specifications/x3d-3.3.dtd</a>"><br>
>> <X3D profile='Core' version='3.3'<br>
>> xmlns:xsd='<a href="http://www.w3.org/2001/XMLSchema-instance" rel="noreferrer" target="_blank">http://www.w3.org/2001/XMLSchema-instance</a>'<br>
>> xsd:noNamespaceSchemaLocation='<a href="https://www.web3d.org/specifications/x3d-3.3.xsd" rel="noreferrer" target="_blank">https://www.web3d.org/specifications/x3d-3.3.xsd</a>'><br>
>> <head><br>
>> ...<br>
>> </head><br>
>> <Scene><br>
>> <WorldInfo title='EmptySceneCoreProfile.x3d'/><br>
>> <WorldInfo title='EmptySceneCoreProfile.x3d'><br>
>> <MetadataSet name='NodeSet'><br>
>> <MetadataBoolean name='BooleanData' value='true false'/><br>
>> <MetadataDouble name='DoubleData' value='1 2 3'/><br>
>> <MetadataFloat name='FloatData' value='4 5 6'/><br>
>> <MetadataInteger name='IntegerData' value='7 8 9'/><br>
>> <MetadataString name='StringData' value='"Empty Scene" "Core Profile"'/><br>
>> </MetadataSet><br>
>> </WorldInfo><br>
>> </Scene><br>
>> </X3D><br>
>><br>
>> The Metadata containerField attributes of the original XML encoding<br>
>> were omitted. This is ok for most Metadata nodes since the default<br>
>> containerField value is 'value'.<br>
>><br>
>> <a href="https://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0_MetadataSet.html#Link561" rel="noreferrer" target="_blank">https://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0_MetadataSet.html#Link561</a><br>
>> defines the default value for the MetadataSet containerField attribute<br>
>> also as 'value'. However, in the example the containerField attribute<br>
>> value for the MetadataSet node needs to be 'metadata' and not 'value',<br>
>> in the x3d.py generated XML.<br>
>><br>
>> I believe this may be an example of what John encountered.<br>
>><br>
>> One option for x3d.py may be to generate containerField attributes for<br>
>> all nodes since x3d.py will know the field name for which a node is<br>
>> the value. Perhaps it suffices to do this for all nodes where the<br>
>> containerField attribute value would not be 'children'. It may not be<br>
>> practical to embed the containerField default values for all nodes in<br>
>> the x3d.py source.<br>
>><br>
>> I just noticed that x3d.py explicitly generates X3D 3.3 xml output.<br>
>> The above only applies to X3D 4.0. However, the same issue persists in<br>
>> a flipped way with X3D 3.3 which has 'metadata' as default<br>
>> containerField value for Metadata nodes. This means in the x3d.py<br>
>> generated output all Metadata nodes except for MetadataSet would need<br>
>> an explicit containerField value of 'value'.<br>
>><br>
>> -Andreas<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>
</blockquote></div></div>