[x3d-public] filling in field default values

[John Carlson]

There are other potential use cases for adding defaults such as converting
XML to …. following the X3dTo*.xslt idea.   I think applying your script to
XML before conversion might be useful, but hopefully a more appropriate
setting of defaults would be done in an SAI library?

I would like to discuss adding a step in xmldiff.js and jsondiff.js which
would add defaults to both sides of the diff.   I am pretty sure that
containerField, the most egregious offender when it comes to diffs, does
not have a default in the standard (but I am aware of default
containerField’s in X3DUOM).

On Sun, Sep 5, 2021 at 1:48 PM John Carlson <yottzumm at gmail.com> wrote:

> Thanks Andreas, it seems like your XML would be useful as a post-processor
> for the XML generated from X3DJSONLD.  Or, in particular, taking X3D JSON
> and converting to STL.   I don’t see a need for such post-processing in
> JSONParser for X3DOM and X_ITE, because I hand off DOM structures to DOM
> parsers (which I hope add defaults).  But adding defaults for STL may be
> quite necessary, for which I would have to convert to XML first, and then
> back to JSON.   Do you have a pure X3D JSON version?   Thanks!
>
> I thought that X3DTidy does what you suggest?  Not sure!
>
> 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/1a71f958/attachment.html>