<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">John,<br>
<br>
There are a few things I am not grasping. I'm asking these
questions to make sure I fully understand the implications and
impetuous for your proposal. I am also concerned because you
mention code. Code in the ISO structure would be a new thing for
the Consortium. It is not something we have done before, and the
Consortium needs to make sure it understands everything before
embarking on such a path.<br>
<br>
1) "...when translating from the JSON encoding to something else,
or process the JSON, we assume that the arrays flatten in an
in-order manner?"<br>
It sounds like you are serializing the MFNode where you drill down
each time an element is an MFNode until an SFNode is reached, the
go back up taking the next, deepest MFNode element to the bottom,
repeating until all of the SFNode elements have been processed.
That would take<br>
<br>
[[[A,B]],[C,[D,E]], F] <br>
<br>
and turn it into [A,B,C,D,E, F]<br>
<br>
where A-F are SFNodes.<br>
<br>
Why can't/shouldn't that be done when constructing the JSON. A
simple example would be great.<br>
<br>
<br>
2) Is the prototype expander code the driving force behind this
request? (3) and (4) are probably only necessary if this answer is
yes. If it is no, what is the driver for expanding the structure
of MFNode?<br>
<br>
3) What is the prototype expanded code that you are referring to.
Is this something you have written that parses an X3D file (which
encoding?) and does something with PROTOs? Is the code
platform-independent? Is this intended to run stand-alone at a
particular point in the work flow or can it be integrated into a
dynamic scene creation, especially if part of the scene comes
during a download after the initial scene is running?<br>
<br>
<br>
4) What does the prototype expander code do? How does it interact
handle code constructed on the fly? How does it handle X3D Script
nodes? Does it depend/handle "AS" and/or directOutput?<br>
<br>
5) If X3D V4 does not have PROTOs, would this be necessary?<br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
<br>
</div>
<blockquote cite="mid:576b1996.d1a7370a.97c1.7759@mx.google.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
<div class="WordSection1">
<p class="MsoNormal">Then I would step back and say can we just
have it for MFNodes in the JSON encoding, and when translating
from the JSON encoding to something else, or process the JSON,
we assume that the arrays flatten in an in-order manner? I do
that anyway for MFNodes in the JSON Loader, it would just be
nice not to have a separate pass or more code to deal with it
in the prototype expander. If the prototype expander is
considered throwaway code or proof-of-concept, then I don’t
think it really matters. If we want to make the prototype
expander into production quality code, then we need to account
for the performance of the code, and likely this means writing
more code, which means longer download times for the code,
which may mean, over the times it’s downloaded, quite a few
bytes. On the other hand, if we go the other way, we have to
consider the processing time for the schema verification and
schema download time. I don’t really have a good feel for
this either way. Perhaps we could go both ways and measure
the difference? We really need some good performance metrics
for this, or someone with an eye for performance. Of the
cuff, I would probably say put in a Group node into the output
of the prototype expander would be the fastest approach, and
only put in a Group node when you are going to have a an array
of arrays. That way, we hope that the processing is done on
the client instead of a shared system.</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Any other solutions?</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">John<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Sent from <a moz-do-not-send="true"
href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a>
for Windows 10</p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New
Roman",serif"><o:p> </o:p></span></p>
<div
style="mso-element:para-border-div;border:none;border-top:solid
#E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="border:none;padding:0in"><b>From:
</b><a moz-do-not-send="true"
href="mailto:roy.walmsley@ntlworld.com">Roy Walmsley</a><br>
<b>Sent: </b>Wednesday, June 22, 2016 1:12 PM<br>
<b>To: </b><a moz-do-not-send="true"
href="mailto:yottzumm@gmail.com">'John Carlson'</a>; <a
moz-do-not-send="true"
href="mailto:Leonard.Daly@realism.com">'Leonard Daly'</a><br>
<b>Cc: </b><a moz-do-not-send="true"
href="mailto:x3d@web3d.org">'X3D Graphics member mailing
list'</a><br>
<b>Subject: </b>RE: [x3d] Proposal for X3D JSON encoding.
Array of arrays foranyarray</p>
</div>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New
Roman",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-GB">John,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-GB">We
briefly highlighted this topic during our WG meeting today.
The concern is that this proposed change could have
significant implications.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-GB">For
example, the abstract specification <a
moz-do-not-send="true"
href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/fieldsDef.html#X3DAbstractField">19775-1,
in 5.2.2 X3DArrayField</a> states “MFxxxx fields may zero
or more values, each of which shall be of the type indicated
by the corresponding SFxxxx field type.”. This effectively
rules out incorporating arrays within arrays. (NOTE: The
quotation above is missing a verb! Another specification
comment required!).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-GB">If
you seriously wish to propose this change then the first
formal step is to submit a <a moz-do-not-send="true"
href="http://www.web3d.org/content/web3d-standards-comment-form">specification
comment</a>. I would suggest that this could be based on
the section of the abstract specification highlighted above.
Then, I would follow the Consortium standard procedure of
raising a Mantis issue, which would then be discussed by the
WG, who would consider all the pros and cons associated with
this proposal, and come to a resolution.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-GB">I
have to revert back to the 19775-1 specification because all
the encodings in the 19776 series are written to ensure that
content written in any one of the encodings conforms to the
requirements of the abstract specification 19775-1. This
commonality permits scenes written in one encoding to be
easily converted to another encoding. It is not permitted to
have, for example, different MFxxxx field content models in
the JSON encoding than in the other encodings, or the
abstract specification.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-GB">Roy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma",sans-serif">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma",sans-serif"> x3d
[<a class="moz-txt-link-freetext" href="mailto:x3d-bounces@web3d.org">mailto:x3d-bounces@web3d.org</a>] <b>On Behalf Of </b>John
Carlson<br>
<b>Sent:</b> 22 June 2016 08:34<br>
<b>To:</b> Leonard Daly<br>
<b>Cc:</b> X3D Graphics member mailing list<br>
<b>Subject:</b> Re: [x3d] Proposal for X3D JSON encoding.
Array of arrays for anyarray<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Times New
Roman",serif" lang="EN-GB"><o:p> </o:p></span></p>
<p><span lang="EN-GB">Again, I am only really asking for MFNode
arrays to contain MFNodes in the JSON encoding/schema. <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB">On Jun 22, 2016 3:30
AM, "John Carlson" <<a moz-do-not-send="true"
href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>>
wrote:<o:p></o:p></span></p>
<p><span lang="EN-GB">Leonard wrote:<o:p></o:p></span></p>
<p><span lang="EN-GB">> My concern is that if the JSON
encoding supports this structure does that mean the
structure needs to also appear in the other encodings? If
so, how would that be done?<o:p></o:p></span></p>
</div>
<p><span lang="EN-GB">I am not so sure the other encodings don't
already support it. Certainly XML does this implicitly.
Perhaps some of the binary encodings don't? idk.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New
Roman",serif"><o:p> </o:p></span></p>
</div>
</blockquote>
<br>
<p><br>
</p>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
X3D Co-Chair on Sabbatical<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>