<div dir="auto">You can follow my path with processing X3DUOM @ X3DJSONLD/src/main/python/…</div><div dir="auto"><br></div><div dir="auto">In particular, I have ways to pull out field types and default parent-child methods for adding and setting children.   The rest of the story is in X3DJSONLD/src/main/node (overrides and defaults missing from the python generated JavaScript).</div><div dir="auto"><br></div><div dir="auto">One could probably easily write a new fieldTypes.js generator using Andreas’ example.</div><div dir="auto"><br></div><div dir="auto">A new mapToMethod.js generator with a fresh approach would also be welcome.</div><div dir="auto"><br></div><div dir="auto">Once you’ve got the X3DUOM parsing down, it’s time to advance to Schema and SAI library and example generators.</div><div dir="auto"><br></div><div dir="auto">Joe, while XML schema remains important, I believe many of our current tools rely on X3DUOM.</div><div dir="auto"><br></div><div dir="auto">John</div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 5, 2021 at 6:30 AM 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)"><div dir="auto">For X3D importers it is necessary to have knowledge about default values for any field. This knowledge could be built into an importer. Alternatively, it is possible to augment an X3D document with explicit values for all fields. Then any importer can just iterate over the given fields and see what it can do with them.<div dir="auto">
<br>
Here is an attempt to do this using X3DUOM, with JS on an online notebook:<br>
<br>
<a href="https://observablehq.com/@andreasplesch/x3d-defaults" rel="noreferrer noreferrer" target="_blank">https://observablehq.com/@andreasplesch/x3d-defaults</a><br>
<br>
It works by recursively visiting all XML scene child nodes, looking up the X3DUOM definition of it's fields and then adding fields with default values which are not already present. It is pretty straightforward and seems to work well enough. It spits out a new js DOM, and new XML as text.<br>
<br>
SF/MFNode fields are ignored. Thinking about it, it may be beneficial to have a NULL value XML representation for such fields:<br>
<br>
<Appearance><br>
  <Material USE='NULL' /><br>
</Appearance><br>
<br>
would be equivalent to<br>
<br>
<Appearance/><br>
<br>
(abusing the USE parameter for lack of a better idea; perhaps an XML comment could also work).<br>
<br>
This way an importer would have to know less about Material as a field value of Appearance. It still would need to know that this means no diffuse and specular, and full emissive='1 1 1'. So perhaps the defaults processing should also already do this. I do not think that there are too many other NULL value defaults with some actual meaning ?<br>
<br>
Is there anything else to be aware of ?<br>
<br>
Now that I went through this exercise, it should be pretty straightforward to do the reverse, eg. remove all field attributes which have default values, for optimization.<br>
<br>
Thanks for reading, Andreas<br>
<br>
--<br>
Andreas Plesch<br>
Waltham, MA 02453<br><div data-smartmail="gmail_signature" dir="auto">---on the phone---</div></div></div>
_______________________________________________<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>