[x3d-public] Why does X3DJSONLD, supposedly a JSON product, deal with containerField?

[John Carlson]

Design notes for X3DJSONLD and x3dschema (repositories on GitHub).  No
questions need to be answered in this email.

X3DJSONLD (the whole package) requires containerField when constructing
stuff in serialized apps (like Java pseudocode below):

HAnimHumanoid.addSkeleton(..joints...)

and

HAnimHumanoid.addJoints(...joint...)

Why? Because I have to construct the "addJoints" or "addSkeleton" from
something.  I've chosen to use "-joints" and "-skeleton" from JSON (I know,
bad word).

So what I do with those "parent node field names (plus a dash)" is take the
field name, remove the dash, capitalize, and prepend with ".add" (shortened
version.  I also look up methods in a parent/child data structure derived
from X3DUOM).

But before that, I convert JSON to DOM, so I just set
containerField="joints" or containerField="skeleton" in DOM. I can do these
things, because X3dToJson.xslt provides the parent node field names (plus
dash) in the form of JSON. I should probably do something else in DOM
besides containerField (why didn't I think of that before)?  I was trying
most unsuccessfully to duplicate XML in round-trip.

I didn't really understand the use of these parent node field names when
designing the JSON encoding (why not just use an off the shelf XML to JSON
tool like JAX-B or similar and be done with it, with no customization
except annotations in X3DJSAIL?)

But I admit, as I've grown to deal with XML, I can see a bit of the beauty
of JSON and VRML using these node fields.

Indeed I could skip this whole "DOM" step. I'm not sure of the design
choice, but it made integration with X3DOM and X_ITE extremely easy, and
VRML could follow this pathway into X3DOM.  Similar designs are being used
in CGE with glTF/glb, AFAIK.

Perhaps the right approach is to start fresh with ECMAScript SAI binding
and the existing JSON WIP encoding, and leave any mention of DOM in the
dust. I'm not the one to design the ECMAScript SAI binding.  People in the
X3DOM and X_ITE communities are much more experienced than I, especially
with 3D, and they know trade-offs.  My primary goal was to round-trip back
to XML for JSON proof-of-concept.  Frankly, I know the minimum amount of
JavaScript necessary for my tasks.  I did sort of read an ES6 book that a
friend gave me, or at least look at code snippets, out of that grew
route.js which could serve as the basis for a new form of routing for a
JSON scenegraph.  Thus came the ProtoExpander, the ScriptExpander, X3D JSON
schema and X3DJSONLD web page. The X3DJSONLD web page is barely standing
these days. ProtoExpander is nearly deprecated, and no one wants the
ScriptExpander.  X3D JSON schema is like a memory.  Learning ProtoExpander
and Serializers, I grew to dislike the way JSON did things, and "saw the
light" of DOM design.  My first JavaSerializer.js (DOM to Java) for
X3DJSAIL was so successful, the design was copied and extended (Thanks to
Don for the chaining idea), and then copied to other languages.

DOM is still used in the XSD validator for JSON.  We could do something
similar for VRML.  But tools like view3dscene already surpass this effort.


MUSINGS
=============================================================
I really still don't know if JSON is the right encoding for the web in
general. It appears to require full state dumps between the server and the
client. A combination of DOM and JSON would be terrific if not accomplished.

VRML really seems to fit a vim/vi mindset. I don't think XML/HTML was
designed with vi in mind, so those encodings don't work for me.  I don't do
any heavy editing of JSON in vi.  I've done much more editing in XML and
VRML.

I've done a lot of editing of VRML in vim, and it seems like a great fit,
for smaller files.  There could be a few features in vim I could use for
XML and JSON that are unexplored. vim keybindings don't stick in my mind as
well any more, so I try to use vi bindings.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20231231/2d9a8b43/attachment.html>