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

[Jung, Yvonne]

> Am 10.10.2014 um 07:57 schrieb Don Brutzman <brutzman at nps.edu>:
> 
> [replying to both Yvonne and Doug]
> 
>> On 10/9/2014 7:35 AM, Jung, Yvonne wrote:
>> +1 for Johannes' proposal --
> 
> me too
> 
>> keep it simple
> 
> again agreed (meaning push complexity into the tools and sophistication into the design, allowing simplicity into the encoding)..
> 
>> and don't think XML-ish.
> 
> well i would say, "don't think non-XML-ish!"  but that is another story.  8)
> 
>> And as already said before: this way, you can directly call JSON.parse() to gen objects.
> 
> sounds great.  we will need to test this.  got example?

JSON is a built-in JavaScript object. This works out of the box: the parse method simply creates a valid JS object from a JSON string. The resulting object tree however still has to be traversed to attach meaning and behavior.

> 
> am also really interested in whether the X3DOM team has already used any JSON for scene graphs internally.
> 
> that kind of code importer would be just the thing for testing the improved numeric version of this X3dToJson exporter at the VR Hackathon next week....
> 
>>> -----Ursprüngliche Nachricht-----
>>> Von: X3D-Public [mailto:x3d-public-bounces at web3d.org] Im Auftrag von doug
>>> sanden
>>> Gesendet: Donnerstag, 9. Oktober 2014 15:49
>>> An: x3d-pulbic mlist
>>> Betreff: Re: [X3D-Public] [x3dom-developers] initial X3D JSON conversion
>>> support using X3dToJson.xslt
>>> 
>>> 
>>> I concur with Johannes on the A) no-defaults and D) explicit child placement (vs
>>> containerFeild), on the design principle "Noise reduction helps adoption".
>>> -Doug
> 
> yes, order is significant and child placement also helps.  containerField only needed if ambiguity or overridden defaults exist (think Collision children vs. proxy).

But neither in classic syntax nor in JSON, if the notation follows the latter. Therefore, your proposal below overcomplicates things and doesn't look like real JSON.

> 
>>> more..
>>> Remember classic / vrml format could explicitly place child fields in the parent
>>> node. It was X3D via xml that needed containerField to disambiguate what field
>>> a child xml element was intended for in the parent node, when it wasn't
>>> obvious (example externProtoDeclares of appearance or shape).
> 
> slight difference Doug:
> 
> actually for all regular nodes, classic/vrml disambiguates by explicitly listing the containerField value every single time (appearance Appearance, material Material, etc.) and the XML encoding allows you to avoid including those default values over and over and over again.
> 
> perhaps more to your point, ProtoDeclare/ExternProtoDeclare/ProtoInstance are written the way they are so that XML validation never has to change.  Different motivating cases, different story.  If the XML changes each time... for example
> 
>    <SpinningTorus/>
> instead of
>    <ProtoInstance name="SpinningTorus"/>
> 
> ...then the scene holding the first case would have to either turn validation off (allowing broken content) or else write new DTDs/Schemas, which is quite difficult and not portable.  Doesn't help authors or end users at all.
> 
>> I haven't
>>> studied JSON, but if it doesn't have a problem - if it has syntax for directly
>>> placing SF and MFnode children in parent node fields like vrml classic did- then
>>> containerField is theoretically un-necessary. In practice, web3d browsers that
>>> never supported vrml/classic will find they need a slight re-arrangement in
>>> their parsing algorithm when transcribing it to support JSON.
> 
> yes, very interesting observation.  i think if you wanted to have something like appearance Appearance material Material you will need something quite similar to the originally given verbose example - excerpt follows:
> 
>      "Shape": [
>      {
>        "@containerField": "children",
>        "@bboxCenter": "0 0 0",
>        "@bboxSize": "-1 -1 -1"
> ,        "Sphere": {
>          "@radius": "1",
>          "@solid": "true",
>          "@containerField": "geometry"
>        },
>        "Appearance": [
>        {
>          "@containerField": "appearance"
> ,          "Material": {
>            "@DEF": "MaterialLightBlue",
>            "@diffuseColor": "0.1 0.5 1",
>            "@ambientIntensity": "0.2",
>            "@emissiveColor": "0 0 0",
>            "@shininess": "0.2",
>            "@specularColor": "0 0 0",
>            "@transparency": "0",
>            "@containerField": "material"
>          },
> 
> the right-hand side after each element contains an array of attributes and child elements.
> 
> if you find another place to put "geometry" "appearance" and "material" (or a reason why they always must appear) please let me know!
> 
> as a result, have added to list "What X3D JSON specification will need to specify:"
> 
> - can omit default attribute values and default containerField values
> 
>>> In theory I should try some JSON before commenting.
> 
> me too.  :0   i think we're all learning here, am very grateful.
> 
> fun quote:
> 
> "In theory, theory and practice are the same.  In practice, they're not." - Yogi Berra
> 
> 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