<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Please don't read the previous mail, it got headings messed up,
argh.<br>
This is the right, complete version:<br>
<br>
<br>
<br>
<div class="moz-text-html" lang="x-western"> 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>
<b><br>
Can we omit the prefixes '@' and '-'?</b>
<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>
<b><br>
<br>
Can we </b><b><b>reduce nesting level?</b></b><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"
</pre>
<div style="margin-left:.5em;">
<pre wrap=""> },
{ "_type": "meta",</pre>
<br>
</div>
<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>
<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>
</div>
<br>
<br>
<b>C</b><b><b>an we remove square braces from </b><b>SF</b><b>Node
fields?</b></b><b></b><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>
<br>
</div>
"<b>@version" in the header should stay a string.</b><br>
<div style="margin-left:.5em;">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.</div>
<small><small> </small></small><br>
<small><small><small><small><small><small> </small></small></small></small></small></small><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>
<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>
</div>
</body>
</html>