[x3d-public] Email Subjects

Don Brutzman brutzman at nps.edu
Fri Nov 20 08:06:52 PST 2015


Thanks for the helpful email etiquette hint Leonard.

backstory: there was a problem for several weeks where none of John Carlson's emails were making it onto the mailing list, they were blocked and only arriving to me.

... maybe not too surprising, it has been an intense conversation for many weeks, with lots of mutual productivity on a challenging topic.

... as subject lines attempted to communicate, multiple interrelated issues are involved. a full JSON Encoding for X3D is a Big Deal.

anyway the email disconnects with John weren't noticed until I tried to link a message for the summary page and found it... missing.

... so everyone let me rattle along on the email list solo, apparently talking to myself, for quite some time without pointing out this problem.

... which maybe isn't terrible. talking to yourself isn't so bad - but talking back is an indicator! :0

To facilitate review like you are doing - thanks especially for that - the running summary of what has been accomplished is carefully maintained up-to-date.  Thus email helps dialog and contributions - totally - but is not the final record of what's what.

	X3D to JSON Stylesheet Converter
	http://www.web3d.org/x3d/stylesheets/X3dToJson.html

We have another X3D JSON Discussion scheduled on Web3D teleconference line at 1000 pacific today. We now appear to have a complete example encoding, as evidenced by all the examples and X3D-Edit deployment. So now the emphasis on implementing loaders and evaluating source code continues - can we improve it further?

	http://www.web3d.org/calendar

All testing efforts are especially welcome. Running code rocks, documentation enables repeatability.  Hope this helps.



On 11/20/2015 6:59 AM, Leonard Daly wrote:
> I have been trying to keep up with the work on JSON encoding, but I have found it difficult as sometimes the topic of the message changes (or evolves) and the email subject does not change. I think it would really help if the authors changed the subject to reflect the message. The standard notation "[was: old-subject]" can be used to help people follow the message-thought evolution.
>
> Thank you,
>
> Leonard Daly
>
> For example the message below had the subject "Re: [x3d-public] announce: updated encoding, X3D to JSON Stylesheet Converter: string arrays, whitespace, UTF-8, Script #source" when something along the lines of "JSON Script encoding" would be a lot easier to follow.
>
>
>
>
>
> On 11/19/2015 5:30 PM, Don Brutzman wrote:
>> The 3-way option for Script #source is now deployed in the examples, described on the X3dToJson stylesheet page, and implemented in X3D-Edit to facilitate testing.  Conversion parameters panel screenshot attached.
>>
>> http://www.web3d.org/x3d/stylesheets/X3dToJson.html#Options
>> https://savage.nps.edu/X3D-Edit/#new
>> https://savage.nps.edu/X3D-Edit/images/X3dToJsonConversionPanel.png
>>
>> On 11/18/2015 4:43 PM, Don Brutzman wrote:
>>> OK and now for the next level for Script source code in JSON form...
>>>
>>>      "When you come to a fork in the road, take it." Yogi Berra
>>>
>>> John:  let's make the #source content a string array, and then authors/tools/files can use any of the three forms equivalently.  first 2 out of 3 pass jslint, likely 3 out of 3 just plain work.
>>>
>>> as before, but in consistent ["string-array"] form:
>>>
>>> - array of one plaintext block string.
>>> - array of one single-line string with all linefeeds and tabs escaped as \n and \t.
>>> - array of multiple one-line strings as shown below.
>>>
>>> A commonly acceptable solution for each of the alternatives takes all the sting out of any choice, we don't have to worry about tradeoff advantages/disadvantages.
>>>
>>> Pretty exciting that a no-lose approach might exist to cope with this situation!  8)
>>>
>>> So I will change stylesheet support for the three alternatives to all be string _array_ and rebuild the examples.
>>>
>>> I hope this fine tuning doesn't interrupt your loader efforts.
>>>
>>> p.s. cosmetic: maybe we should rename #source to #sourceText or somesuch - a more descriptive key name might also be preferable.
>>>
>>>
>>> On 11/17/2015 10:17 PM, Don Brutzman wrote:
>>>> [summary: from plaintext block to total escapism and now to string array for #source block]
>>>>
>>>> On 11/17/2015 7:21 AM, John Carlson wrote:
>>>>> Why isn't an array of strings acceptable?
>>>>
>>>> On 11/17/2015 7:23 AM, John Carlson wrote:
>>>>> It's a typical javascript pattern to create arrays of strings and then join them.
>>>>
>>>> glad to hear it!
>>>>
>>>> If arrays of json strings are typical and acceptable and not an undue complication for plain old javascript programmers, then it is certainly fine with me.  I strongly believe that human readability is important.  Quoted strings are surely better than garble.
>>>>
>>>> It is no trouble for me to export .x3d to .json #source that way as well.  I have added another option to the stylesheet switch tonight to produce that alternative.
>>>>
>>>> Example attached, excerpt follows.  Hmmm, not too bad, and certainly not confusable.
>>>>
>>>> I will again regenerate all examples in that form if opinions are leaning that way.
>>>>
>>>> ==========================================
>>>>              "-children":[
>>>>                { "Script":
>>>> [...snip...]
>>>>                    "#source":[
>>>> "ecmascript:",
>>>> "function initialize ()",
>>>> "{",
>>>> "    checkCoordinatePoints ();",
>>>> "}",
>>>> "function checkCoordinatePoints ()",
>>>> "{",
>>>> "    // A parallelepiped has three sets of four parallel edges; the edges within each set are of equal length.",
>>>> "    // Quality assurance: check that lengths of corresponding sides match.",
>>>> "    ",
>>>> "    edge01 = length2(point[0], point[1]); // top",
>>>> "    edge12 = length2(point[1], point[2]);",
>>>> "    edge23 = length2(point[2], point[3]);",
>>>> "    edge30 = length2(point[3], point[0]);",
>>>> "    edge45 = length2(point[4], point[5]); // bottom",
>>>> "    edge56 = length2(point[5], point[6]);",
>>>> "    edge67 = length2(point[6], point[7]);",
>>>> "    edge74 = length2(point[7], point[4]);",
>>>> "    edge04 = length2(point[0], point[4]); // sides",
>>>> "    edge15 = length2(point[1], point[5]);",
>>>> "    edge26 = length2(point[2], point[6]);",
>>>> "    edge37 = length2(point[3], point[7]);",
>>>> "    ",
>>>> "    epsilon = edge01 * 0.001;",
>>>> "    ",
>>>> "    if      ((Math.abs(edge01 - edge23) > epsilon) ||",
>>>> "             (Math.abs(edge23 - edge67) > epsilon) ||",
>>>> "             (Math.abs(edge67 - edge45) > epsilon) ||",
>>>> "             (Math.abs(edge45 - edge01) > epsilon))",
>>>> "         Browser.println ('Warning, mismatched parallelopiped sides 02/33/45/67');",
>>>> "    else if ((Math.abs(edge30 - edge12) > epsilon) ||",
>>>> "             (Math.abs(edge12 - edge56) > epsilon) ||",
>>>> "             (Math.abs(edge56 - edge74) > epsilon) ||",
>>>> "             (Math.abs(edge74 - edge30) > epsilon))",
>>>> "         Browser.println ('Warning, mismatched parallelopiped sides 30/12/56/74');",
>>>> "    else if ((Math.abs(edge04 - edge15) > epsilon) ||",
>>>> "             (Math.abs(edge15 - edge26) > epsilon) ||",
>>>> "             (Math.abs(edge26 - edge37) > epsilon) ||",
>>>> "             (Math.abs(edge37 - edge04) > epsilon))",
>>>> "         Browser.println ('Warning, mismatched parallelopiped sides 04/15/26/37');",
>>>> "}",
>>>> "function length2 (pointA, pointB)",
>>>> "{    ",
>>>> "    return Math.sqrt((pointA.x - pointB.x)*(pointA.x - pointB.x) +",
>>>> "                     (pointA.y - pointB.y)*(pointA.y - pointB.y) +",
>>>> "                     (pointA.z - pointB.z)*(pointA.z - pointB.z));",
>>>> "}",
>>>> "function set_point (eventValue)",
>>>> "{",
>>>> "   // input eventValue received for inputOutput field",
>>>> "    point = eventValue;",
>>>> "    checkCoordinatePoints ();",
>>>> "}"
>>>> ]
>>>>                  }
>>>>                }
>>>>              ]
>>>> ==========================================
>>>>
>>>> Example reassembly to join strings back together in javascript:
>>>>
>>>> http://stackoverflow.com/questions/2392766/multiline-strings-in-json
>>>>> Once parsed, I just use myData.modify_head.join('\n') or myData.modify_head.join(),
>>>>> depending upon whether I want a line break after each string or not.
>>>>
>>>> Wondering, what would that join() code specifically look like for an X3D JSON loader?
>>>>
>>>> Looking forward: seems like a group/community decision if we want to specify a string array as X3D JSON default for #source blocks.
>>
>> all the best, Don
>>
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> --
> *Leonard Daly*
> X3D Co-Chair
> Cloud Consultant
> President, Daly Realism - /Creating the Future/
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>


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



More information about the x3d-public mailing list