[X3D-Public] [x3dom-developers] initial X3D JSON conversion support using X3dToJson.xslt

[Don Brutzman]

Thanks for all the great feedback & discussion, Johannes Yvonne John and Len.

First, please be assured that we're NOT trying to
- turn JSON into XML.  all encodings have relative strengths, weaknesses and idiosyncrasies.
- create One Tool That Rules Them All And In The Darkness Binds Them

On 10/9/2014 5:52 AM, Behr, Johannes wrote:> Thanks for your effort.
>
> My comments on the code example:
>
> -------------------
> Group": [
>    {
>      "@bboxCenter": "0 0 0",
>      "@bboxSize": "-1 -1 -1",
>      "@containerField": "children"
> ,    "Viewpoint": {
>        "@DEF": "ViewUpClose",
>        "@centerOfRotation": "0 -1 0",
>        "@description": "Hello world!",
> --------------------
>
> A) Why writing default values? They are skipped in every other encoding?

Simply a side effect that will go away, listed in the TODO section.

This is a limitation (or feature) of XSLT... the engines that I have used say "aha there is a DTD" or "aha there is a schema" and fills in all of the default values.  So that is the tree loaded into memory that gets manipulated.

In other stylesheets I have a set of rules that strip out default values.  Haven't integrated that yet.

Before writing more code am looking into whether there is a way to suppress that feature of XSLT.

> B) Why is there always @ in front of every field name?

As Len explained, this is to distinguish element names from attribute names to simplify round tripping.

This is also well documented on our page and on other XML-JSON sites.

The JSON spec does not really say anything about aligning with XML data models.

> C) Why not using the javascript native types for numbers and booleans?
>
> My encoding suggestion:
>
> Group": [
>   {
>     "bboxCenter": [0 0 0],
>     "bboxSize": [-1 -1 -1],
> ,    "children" : [
> 	"Viewpoint": {
>            "DEF": "ViewUpClose",
>            "centerOfRotation": [-0 -1 0],
>            "description": "Hello world!",
> }
>
> Faster to parse (using native types) more compact and more explicit in regards to the hierarchy connections.

Agreed + thanks for educating me, makes perfect sense.  When reading the processing diagrams in the JSON spec it looked like they were treated equivalently, I missed that possibility and landed on the wrong answer.

To accomplish this means that the converter will need to be type-aware on a field-by-field basis when reading values.  When programming this, I'll need to trap booleans and strings first, then treat everything else as number.

Will fix in next revision.

JSON question #1, wondering which is correct for a singleton number?

	"transparency": [1],
or
	"transparency": 1,

There are very few examples in the JSON spec.  A strict reading there seems to permit either form: an array with a single value, or else a singleton number with no surrounding brackets.

JSON question #2, wondering which is correct for an MFVec3f value, single array or array of arrays?

	"keyValue": [0 0 0 1 1 1 2 2 2],
or
	"keyValue": [ [0 0 0], [1 1 1], [2 2 2] ],

Incidentally all this adds additional reasons why we will need to formally specify the JSON encoding for X3D, so that array and numeric and boolean types are correctly handled in a different manner than strings.

> D) Why an extra "@containerField"?

This is the same as issue (A).  Each X3D element/node has a default containerField value so that they do not have to be written out in a file.  Default containerField values will go away, except when default values are overridden - a fairly infrequent occurrence.

updated status:
===========================================
<!--
Working:
- elements, attributes, comments
- Square and squiggly brackets, commas
- escaping quotation marks

TODO
- differentiate typing of string versus number and boolean values
- handling of singleton numeric values, e.g.
	"transparency": [1],
or
	"transparency": 1,
- handling of MFVec arrays
	"keyValue": [0 0 0 1 1 1 2 2 2],
or
	"keyValue": [ [0 0 0], [1 1 1], [2 2 2] ],
- elimination of default X3D attribute values
- handling special characters
- CDATA text (for example, Script content)
- round-trip testing using a JSON-to-XML converter
- embedded support in X3D-Edit

What X3D JSON specification will need to specify:

- handling of numeric, boolean and string values
- handling of MFVec arrays
- @attributeName
- "#comment"
- "#CDATA'

Not possible:
- embedded JSON comments disallowed
     http://www.quora.com/How-do-I-write-comments-inside-a-JSON-document
-->
===========================================

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