[x3d-public] filling in field default values

[John Carlson]

You can follow my path with processing X3DUOM @ X3DJSONLD/src/main/python/…

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).

One could probably easily write a new fieldTypes.js generator using
Andreas’ example.

A new mapToMethod.js generator with a fresh approach would also be welcome.

Once you’ve got the X3DUOM parsing down, it’s time to advance to Schema and
SAI library and example generators.

Joe, while XML schema remains important, I believe many of our current
tools rely on X3DUOM.

John


On Sun, Sep 5, 2021 at 6:30 AM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> 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.
>
> Here is an attempt to do this using X3DUOM, with JS on an online notebook:
>
> https://observablehq.com/@andreasplesch/x3d-defaults
>
> 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.
>
> SF/MFNode fields are ignored. Thinking about it, it may be beneficial to
> have a NULL value XML representation for such fields:
>
> <Appearance>
>   <Material USE='NULL' />
> </Appearance>
>
> would be equivalent to
>
> <Appearance/>
>
> (abusing the USE parameter for lack of a better idea; perhaps an XML
> comment could also work).
>
> 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 ?
>
> Is there anything else to be aware of ?
>
> 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.
>
> Thanks for reading, Andreas
>
> --
> Andreas Plesch
> Waltham, MA 02453
> ---on the phone---
> _______________________________________________
> 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/20210905/0d04fc20/attachment-0001.html>