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

[Don Brutzman]

[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?

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).

>> 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