<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Don and all,<br>
<br>
before jumping in on this, i've read all the discussions preceding
this.<br>
Took me about 3 hours. One can do this only on spare time.<br>
But i was happy to see how people bring good arguments, factual and<br>
respectful (of course).<br>
And i would have argued into the same directions, too.<br>
<br>
Though you say yourself that your current iteration of the encoding
needs investigation,<br>
<blockquote type="cite">Still haven't compared it to interesting
design alternatives previously posted by Cecile, Yvonne, Kristian,
John and others. Continued exploration should help a "best of
breed" emerge, the problem space continues to shrink.
</blockquote>
i would like to mention a few things that come to mind.<br>
Maybe just to come up with the same what you would.<br>
<br>
<li><b>Can we omit the prefixes '@' and '-'?</b></li>
<div style="margin-left:.5em;">i understand that there are some
conventions in XSLT, XPATH, etc., but<br>
do we need to<b> keep them</b><b> in JSON?</b><b><br>
</b> The big point of JSON is that you can pass a JSON string to
JSON.parse()<br>
and receive an <b>object tree of JavaScript objects</b>. With key
value pairs.<br>
In JavaScript the '@' or '-' characters <b>don't feel native</b>
as key names.<br>
To rephrase the above question, why have them there?<br>
<br>
Moreover, they make the keys <b>not form valid variable names</b>,
so one can't<br>
use this syntax:<br>
<big><tt>myMaterial.transparency= .5;</tt></big><br>
but must use <b>more noisy syntax</b>:<br>
<big><tt>myMaterial</tt><tt><b>['@</b></tt><tt>transparency</tt><tt><b>']</b></tt><tt>=
.5;</tt></big><br>
This is what Cécile has pointed out already today (now yesterday).<br>
<br>
i do understand that some convertors need to have an indication
whether<br>
something is a field (attribute) or a child node, but is it really
so?<br>
if so, we can omit at least one of the two. I'd vote for the '@'
as it appears more often.<br>
</div>
<br>
<div style="margin-left:.5em;">i feel there are more nesting levels
than would be necessary.<br>
Is there a limit in the JSON spec? (hope not).<br>
Consider the meta tag in the header:<br>
<pre wrap="">"head":[
{ "meta":
{
"@content":"HelloWorld.x3d",
"@name":"title"
}
},
{ "meta":</pre>
There is a '[', and two '{'s to get from the 'head' field to the
'@content' field.<br>
That's <b>3 nesting levels</b>.<br>
With Kristians / Céciles approach, there are only two braces to
cross, a square<br>
one and a curly one:<br>
<pre wrap="">"head":[
{ "_type": "meta",
"content": "HelloWorld.x3d",
"name": "title"
},
{ "_type": "meta",</pre>
<br>
</div>
<div style="margin-left:.5em;">That's now hard to explain. <br>
The inner pair of curly braces (green ones) feels natural to me.<br>
It envelopes the name-value pairs describing the Transform node in
question.<br>
That's what curly braces are for in JSON.<br>
<br>
But the outer curlies (red ones) look to me like a workaround for
something. <br>
Like the workaround for the fact that the node names are not
unique, but key<br>
names must be unique.<br>
This forms a JavaScript object - curly braces denote objects in
JSON - that consists<br>
of a single field, which is the node type and has the actual node
description as the<br>
value.<br>
It is an <b>additional nesting level</b>, that does not exist in
the data model of X3D.<br>
i think that should be avoided.<br>
<br>
Normally when you have things that have no unique name but their
order is significant,<br>
you put them into an array. <br>
That array already exists in your encoding. It is the '[' and ']'
surrounding the Transform<br>
node. The only thing that should be eliminated is the red curlies.<br>
<br>
Again, the "_type" approach of Cécile and Kristian solves this.<br>
<small><small><small><small><small><small><small><small> </small></small></small></small></small></small></small></small><br>
<big><tt><font color="#009900">{</font></tt><tt> "_type":
"Transform", fields-of-the-Transform </tt><tt><font
color="#009900">}</font></tt></big><br>
</div>
<br>
<div style="margin-left:.5em;">i see this in the Shape node:<br>
<pre wrap="">"-geometry": <font color="#3333ff">[</font> <font color="#990000">{</font> "Sphere": <font color="#009900">{</font> fiels-of-the-Shape <font color="#009900">}</font> <font color="#990000">}</font> <font color="#3333ff">]</font>
</pre>
with the transparency field, we agreed on having no '[' and ']'for
<b>SF</b> fields.<br>
Similarly, there is no need for them in <b>SF</b>Node fields.<br>
i think the blue squares should be removed here.<br>
<br>
</div>
<div style="margin-left:.5em;"><b> </b> Version strings look like
numbers, but sometimes one wants to add letters. E.g. for
indicating<br>
beta versions or release candidates. Don't know how this applies
to a spec though.<br>
Besides that, the number 3.3, for example, is not exactly
representable as a binary floating point<br>
number, i guess. It may be represented internally as
3.2999999999999987 or such.<br>
<br>
These are my suggestions. Would be interesting if that JavaScript
book you mentioned has<br>
reasons against them.<br>
<br>
<br>
best regards, <br>
<br>
<i>Herbert Stocker</i><br>
</div>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 09.03.2015 16:28, Don Brutzman
wrote:<br>
</div>
<blockquote cite="mid:54FDBC31.40406@nps.edu" type="cite">On
3/9/2015 2:46 AM, Roy Walmsley wrote: <br>
<blockquote type="cite">Don,
<br>
<br>
Great that you are making progress.
<br>
</blockquote>
<br>
Thanks Roy. It is definitely challenging but appears to be
do-able. <br>
<br>
Douglas Crockford's "JavaScript: The Good Parts" is a
fundamentally important reference. <br>
<br>
<blockquote type="cite">I have two questions, if I may. Apologies
in advance if it simply my lack of
<br>
knowledge and understanding.
<br>
</blockquote>
<br>
All help is much appreciated, questions are really important.
Thanks. <br>
<br>
btw if you find anyone with full knowledge and understanding,
please invite them over immediately! 8) <br>
<br>
<blockquote type="cite">1) Why does a container field need to
have a different prefix to the other
<br>
attributes (i.e. "-" as opposed to "@")?
<br>
</blockquote>
<br>
The @ symbol is commonly used in XML XPath, XSLT etc. to indicate
the name of an attribute. Didn't want to overload that semantic
usage further. <br>
<br>
I applied the - symbol to prefix containerField labels for node
arrays to see how it looks and to possibly simplify processing.
Without that distinguishing symbol, a parser trying to reconstruct
an X3D scene graph from JSON might need deeper knowledge of how
X3D works. So it is experimental. <br>
<br>
Organizing child arrays by using the field names of X3D nodes is
an asset we have that allows each node to be handled as a uniquely
keyed object - the "O" in JSON. (This approach is not possible in
other XML to JSON patterns, where generally XML child elements
don't have such a unique key or label.) <br>
<br>
I suspect that the - symbol prefix might be able to go away, or be
further improved, when we get to using these a bit more. Not
clear yet. <br>
<br>
Meanwhile (after briefly sleeping on it) I've added the rest of
what is needed for converting the X3D header. Non scene-graph
nodes (X3D, head, component, meta, unit, Scene) are simple JSON
objects that are now included. Note that they have no
containerField and in some cases no attributes at all, so the
design pattern here is simpler and a little bit different than the
rest of the scene graph. <br>
<br>
Completely converted HelloWorld.json attached. Looks like a pair
of slightly different design patterns (first for header and then
for scene graph) are required and holding together OK so far.
Still passes jslint in its strictest mode. <a class="moz-txt-link-freetext" href="http://www.jslint.com">http://www.jslint.com</a>
<br>
<br>
Incidentally the need for a slight hybrid approach like this
design may be part of why a single approach has been a bit elusive
so far. Still haven't compared it to interesting design
alternatives previously posted by Cecile, Yvonne, Kristian, John
and others. Continued exploration should help a "best of breed"
emerge, the problem space continues to shrink. <br>
<br>
Conversion stylesheet updates committed to <br>
<a class="moz-txt-link-freetext" href="https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/X3dToJson.xslt">https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/X3dToJson.xslt</a>
<br>
<br>
Extra: added some design comments on whether a special JSON header
is needed (probably not) or DOCTYPE information is needed (not). <br>
=======================================================================
<br>
7. Apparently not possible or not needed. <br>
<br>
- Embedded JSON comments are specifically disallowed by JSON
specification <br>
and so round-trippable inclusion must be a custom feature of
this encoding. <br>
<a class="moz-txt-link-freetext" href="http://www.quora.com/How-do-I-write-comments-inside-a-JSON-document">http://www.quora.com/How-do-I-write-comments-inside-a-JSON-document</a>
<br>
- No JSON-unique header. Can optionally use X3D/head/meta
name=value pairs <br>
(if capturing full document) or comments in a scene-graph
fragment <br>
or even an X3D Metadata node. However for anything intended to
be <br>
interoperable/reusable, consistency and repeatability is needed.
<br>
Leaving the output JSON as simple as possible avoids code
problems and <br>
provides programmers with the greatest possible flexibility.
Further <br>
analysis will show if a JSON header is needed, probably a
non-problem. <br>
- DOCTYPE information is dropped. This is commonplace for XSLT
and does <br>
not appear to be needed in the JSON encoding. If actually
needed by someone, <br>
such information can be reconstructed simply by using the X3D
version number. <br>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#Validation">http://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#Validation</a>
<br>
=======================================================================
<br>
<br>
<blockquote type="cite">2) How is it with routes and prototypes,
including 'IS' statements?
<br>
<br>
Roy
<br>
</blockquote>
<br>
Great question, that is the next level. Script, field, CDATA
source blocks, ProtoDeclare, IS/connect, ExternProtoDeclare and
fieldValue might require some special handling in the stylesheet,
though I suspect that these patterns will be able to handle them
just fine. I'll need another session (and more strong coffee!) to
confirm that satisfactorily. <br>
<br>
Given that this hybrid approach is now different from other
XML-to-JSON converters, we'll probably also need to write a
Javascript program to parse and then write the JSON back out as
XML .x3d in order to confirm the lossless round-trip requirement.
JsonToX3d.js I suppose. <br>
<br>
If nothing else, all of this design variety illustrates the value
of finding an acceptable JSON encoding that can be reused
consistently. <br>
<br>
all the best, Don <br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
x3d-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>
<a class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
</pre>
</blockquote>
<br>
<li><b>Can we reduce nesting level?</b></li>
<li><b>Why </b><b><font color="#990000">{</font></b><b>
"Transform": </b><b><font color="#009900">{</font></b><b>
fields-of-the-Transform </b><b><font color="#009900">}</font></b><b>
</b><b><font color="#990000">}</font></b><b>?</b></li>
<li><b>Can we remove square braces from </b><b>SF</b><b>Node fields?</b></li>
<li><b>"@version" in the header should stay a string.</b><br>
</li>
</body>
</html>