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

Don Brutzman brutzman at nps.edu
Fri Feb 20 03:15:01 PST 2015


On 2/18/2015 11:32 PM, John Carlson wrote:
> VRML != JSON.  JSON is more like XML.

yep

> On Feb 19, 2015 1:30 AM, "John Carlson" <yottzumm at gmail.com <mailto:yottzumm at gmail.com>> wrote:
>
>     One more thing.  JSON doesn't guarantee ordering between name/value pairs in an object.  If you want ordering, you must use arrays.

yes

that is why the current X3dToJson stylesheet doesn't try to impose ordering where it didn't exist in the first place.

- Nodes/elements are ordered by sequence and parent/child relationships.
- Simple (non-node) fields/attributes have no order within an element
- These hold true for X3D/XML and DOM.  An author might wish for it, but any XML tool can change attribute order legally.

Limitation in current X3dToJson encoding:  the conversion is DOM based, and DTD/Schema aware, so default values get autoinserted.  At some point we can add the work to strip them out.

>     On Feb 19, 2015 12:21 AM, "John Carlson" <yottzumm at gmail.com <mailto:yottzumm at gmail.com>> wrote:
>
>         How does the X3D JSON encoding handle two Shapes or Transforms or Groups of the same type at the same depth in the tree with the same parent?  Do you modify the tree structure significantly?  I'm not that familiar with the schema.  I just know you're going to have to do something else in JavaScript, even if your JSON parses and works.  You can't use the JSON directly as Javascript.   JSON  != JavaScript.  We desire a *JavaScript* and JSON encoding.

This is a crucial point and I'm really glad you are raising it.

If we think about use cases for Javascript applications loading X3D models, I think they are most interested in reusing geometry for their own nefarious/magnificent purposes.  Javascript programmers are likely less interested in X3D event models, Scripts, protos and whatnot.  Library loaders might convert such things to match their paradigm, or might also ignore non-geometry nodes completely.

Rephrase, Let JSON be JSON (a subset that is good for data objects) and Javascript be Javascript (a full-blown programming language).

Not trying to downplay or avoid anything, just looking at what the most common uses of an X3D scene encoded as JSON might be.

Such an idea actually brings us full circle to the design premise of all the scene encodings (XML .x3d, Classic VRML .x3dv, binary .x3db) which is to completely/compatibly represent an X3D scene, period.

If we achieve that with JSON, making common geometry constructs easy for programmers to access, then great they will do so.  If we also try to tell them "For Advanced Graphics Using X3D JSON You Must Program Your Javascript Application This Way" they will laugh.

Viva la difference, programming styles and practices will always vary and evolve.  Whatever works.

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



More information about the x3d-public mailing list