[x3d-public] filling in field default values

[John Carlson]

There is Saxon-CE (v2) and Saxon-JS (v3) available for web, but these are
not compatible with our current stylesheet for creating JSON and processor
(saxon9he.jar).   As is evidenced on this mailing list, use of more
advanced (xslt3) processors with X3dToJson.xslt leads to non-validating
JSON.   These issues have been reported.   It would be nice if we had a
solution for the web, and I think the first step is seeking out why xslt3
produces errors and bad JSON.  Once the stylesheet or input files are fixed
and output is compared successfully to saxon9he.jar, we can then start
testing on the web.  Yay!

I have tried reporting errors as requested by the stylesheet.

Andreas, if you’d like to pick this task up, there are scripts that have
xslt3 commented out in X3DJSONLD/src/main/shell

I don’t know if they are compatible with WSL…maybe with a few tweaks.   I
believe that xslt3 requires nodejs and npm.

This sort of JavaScript and web stylesheet processing is a good
introduction to our stylesheet system.   It would be really cool to see
X3D-Edit features ported to the web!

And I could really use a good XML to JSON conversion for X3DJSONLD GUI!

We canonicalize before comparing in roundtriping…defaults I don’t think are
an issue.

John

On Sun, Sep 5, 2021 at 3:24 PM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> SAI: True, SAI libraries could have that option in some way. Keep in
> mind that adding defaults is somewhat incompatible with round-trip
> capability.
>
> JSON: It should be possible to come up with a version for the JSON
> encoding. It should not be too hard to walk through that structure
> similar to XML nodes. Looking up the defaults would work the same.
>
> containerField: Is not strictly a field but I think the standard says
> what the default is for any node, mostly 'children'. Is not currently
> considered in default normalization.
>
> x3dtidy: seems to do the opposite,eg. removes fields with default
> values. xslt2.0 is not really an option anyways for the web since it
> requires saxon.
>
> Andreas
>
> On Sun, Sep 5, 2021 at 3:20 PM John Carlson <yottzumm at gmail.com> wrote:
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20210905/371b6d4f/attachment-0001.html>