[x3d-public] filling in field default values

[Andreas Plesch]

Thank you for your response.

On Sun, Sep 5, 2021 at 4:38 PM Joseph D Williams <joedwil at earthlink.net> wrote:
>
> For X3D importers it is necessary to have knowledge about default values for any field. ..
>
>
>
> For all fields. and also the data type(s) and their relation to x3d data types and lots of other details.
>
> In all cases, except the couple of exceptions,  the default or acceptable value is given in the standard xml documentation.
>
> There is a tool that can use xml documentation to validate field values and give defaults for all the fields in all the nodes, with pertinent exceptions – the keystrokes in the standard and the next best thing, all of our glorious x3d xml documentation. For those that specify options, then and for those maybe trust the author our learn more about where tht pesky field is and what it represents.?
>
> Anyway, my only point is that if there is doubt about any default or given value or form then use the official x3d xml documentation latest and greatest to validate.
>
> Exceptions? Then you gotta understand what those exceptions are.

X3DUOM is an attempt to capture some of the spec. in a fixed
structure, based on node signatures. In terms of default values for
SFNode which is often NULL, X3DUOM does not currently include spec.
information on how to interpret such values. For example, a null
Material means a white emissive only material. It would make X3DUOM
more valuable if it would capture such information as well.

>
> Like the one where the first humanoid joint is container skeleton and the rest of the joint nodes are children – its obvious when you see the Classic user code but for analyzing the the xml any algorithm to validate HAnimJoint containerField has to understand the skeleton field.  Also for protos, the author or the tool has to understand what is being specified and maybe even why.
>
> To me the hardest part has to be validating that the stuff to be imported has its known and expected form available and that the import/transcoding tool can produce appropriate x3d user code from what is input so that the result x3d user code can be validated according to x3d xml documentation. To be useful, whatever is input must produce nodes and fields for basic x3d user code for validation and of course import/exports has to go both ways, exporting to canonical form in either direction.

One approach is to assume that the input is already validated.
Assuming that all default values are explicit also helps a lot with
initial efforts. Frustrating to a user but ..

It is also important to think about how to balance fidelity of
importing with available resources, including capabilities of the
importing system. In other words, it can be very useful to have an
imperfect import rather than not have any. It can also be very useful
to import even if not able to export. For example just importing
Shapes without any runtime has great value.

I am currently experimenting with BabylonJS, a JS game engine, sort of
similar to ThreeJS. Here is a very limited proof of concept:

https://observablehq.com/@andreasplesch/x3d-to-bjs

Thanks again for sharing stimulating thoughts,  Andreas

>
> Thanks,
>
> Joe
>
>
>
>
>
> From: John Carlson
> Sent: Sunday, September 5, 2021 12:20 PM
> To: Andreas Plesch
> Cc: X3D Graphics public mailing list
> Subject: Re: [x3d-public] filling in field default values
>
>
>
> 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
>
>



-- 
Andreas Plesch
Waltham, MA 02453