[x3d-public] X3D JSON encoding: Purpose and Comments

[John Carlson]

I think that in designing an encoding, one needs to be aware of relevancy
of local data.  Is all the data we need restricted to this node?  Is it
easy to store/retrieve if it's elsewhere?  If I'm expanding prototypes, can
I easily delete a single node and get rid of the prototype?  These are
handy things which I think are in the present design which should be in any
potential design.

Thanks, John
On Dec 24, 2015 7:39 AM, "Cecile Muller" <newsletter at wildpeaks.fr> wrote:

> Good morning list,
>
>
> > I think the significance of the “$” is a tag, type, class, etc.  In my
> encoding, this was “jsontag”
> > It essentially encodes the type of the JSON object in the JSON object.
> Cecile, please correct me if I am wrong.
>
> Yes it's exactly that, it's just a property for the node type :)
> Here's some more infos from last year about why I picked this specific
> structure:
> https://github.com/wildpeaks/json-scenegraph/issues/1
>
>
> > 4) Do we want a parser/loader to convert everything as is, or to perform
> some optimizations
> > along the way to eliminate comments and structures such as
> content/children,
> > so that the internal representation is much closer to the 3D structures
> required?
>
> Personally I never use JSON5 because I prefer sticking to native JSON
> parsers.
> But on the other hand, I also wouldn't use comments or scripts in a 3D
> JSON file
> (for example I'd use ES6 modules that generate JSON or engine-specific
> typed objects),
> but that's only an option because my main target nowadays is Javascript,
> whereas X3D JSON isn't targeting a specific language.
>
> That's why I suggested JSON5 as an alternative that doesn't require
> Javascript
> yet common-enough that it's still easy to parse.
>
> But using #comment nodes would be fine too, the 3d engine can just filter
> them out.
>
>
> > Purpose:  Avoid XML and the DOM api (probably not the best reason).  The
> loader uses the DOM api, so…
> > Purpose:  Near native access times.  JavaScript only.  Does not apply to
> parsing.
>
> Another reason why JSON is more convenient to me than XML is that I like
> to keep the application data mutations
> in a web worker (to keep the heaviest calculations neatly tucked away from
> the main page render thread),
> and web workers don't have access to the DOM, and can't use the XML parser.
>
>
> > When you load a JSON file into the DOM don't you get the DOM interface
> anyway?
>
> No, JSON.parse returns a javascript data type, it's not in the DOM
> (but it can be used to make an equivalent structure in the DOM).
>
>
> > I've added a few other details on the X3D to JSON Stylesheet page -
> please review and advise on what else to add.
> > http://www.web3d.org/x3d/stylesheets/X3dToJson.html#Muller
>
> Thanks Don, although could you slightly modify the description because I
> use a vanilla JSON structure.
> JSON5 was just one single example of how one could extend the structure to
> support
> an optional feature like comments, but I do not require JSON5 at all,
> I even advise scene authors to use Metadata nodes instead when possible,
> in order to keep it as a clean vanilla JSON.
>
>
> Happy holidays,
> Cecile
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20151224/aad4a59b/attachment-0001.html>