[x3d-public] [x3dom-users] simple X3D -> JSON -> X3DOM, D3.js

[Don Brutzman]

onward and inward...

On 2/22/2015 5:55 AM, Kristian Sons wrote:
> Hi,
>
> trying to structure the discussion a bit:
>
> I guess the main question is if to a) start from XML encoding and use a generic XML to JSON converter, or b) to start from the X3D data structure and create something that reflects and fits well to the X3D data structure.
[...]
> On 2/23/2015 6:41 AM, Don Brutzman wrote:
> Thanks for the great analysis Kristian, sounds like we are all gradually understanding these worthy design challenges more and more deeply.  We need to review each of your points in detail.
>>
>> Whether containerField information is implicit (as with XML encoding) or explicit (as with ClassicVRML/VRML encodings) is indeed a key design choice.  Both are certainly workable and each has tradeoffs such as you've listed.

Building on the explicit approach:

>> On 2/23/2015 1:24 PM, Douglas Crockford wrote:
>>> I recommend failing on duplicate keys.

This truism that keys ought to be unique ripples backwards into our design discussions helpfully.  Are there keys we might use?

Obviously can't be DEF/USE id's, they are too sparse and we simply can't auto-create DEF values for every element/node while still preserving round-trip consistency.

Turning prior design questions around somewhat:  can we have a local key for each X3D node (element) in a scene graph?

Don McGregor here at NPS also had some interesting insights: field names for object trees are locally unique, and could be treated as keys, each within the local scope of each individual parent node/object.

While elements in most XML documents don't have an information item that could serve as a key, we do have field names that pertain to each X3D element.  So we might be able to come up with a key-like approach (field names, aka containerField in X3D XML parlance) that works on a node-by-node, object-by-object basis throughout the document tree being created in JSON.

So if we take path (b), with explicit inclusion of field-name containerField values, we can probably achieve local uniqueness within each object/node and strict validation like John has been advocating.  For example, multiple sibling Transform nodes would appear as entries in a "children" [] array of some sort.

Looking at Cecile's encoding, she gets close to that VRML97/ClassicVRML style of encoding, but for the moment it appears there are some redundancies in there that might be further optimized.

Continued scrutiny and considering multiple alternatives will likely be helpful.

>  [...] suggest that eventual consensus this design choice is primarily based on what approach is most useful to Javascript programmers, especially those writing loaders for Javascript APIs such as X3DOM, three.js, D3.js, et al.

rephrase: implement, evaluate, repeat until done.  so, at the finish line, failure is not an option!  8)

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman