[x3d-public] X3D JSON encoding: refactoring, simplifying handling of #comment and #ROUTE

[Don Brutzman]

Thanks Leonard for the helpful information regarding how order is often not maintained in hash maps.  Agreed that is common to a number of languages.

On 1/4/2016 7:46 AM, Leonard Daly wrote:
> On 1/4/2016 5:06 AM, John Carlson wrote:
>> If all else fails, we can think about adding an index to the comment that shows where it is.  Or #precomment and #postcomment.
>
> I have not been following this thread as closely as I probably should.
>
> I think what is being discussed is the location of comments in the JSON encoding compared their original location in the XML encoding. If that is not the case, then ignore the rest of this message and let me know.
>
>
> In all translators/parsers dealing with hash (aka objects in JavaScript), I have always seen the disclaimer that the order of the original data cannot be guaranteed to be preserved in the data structure after translating/parsing. For example (using PHP and Perl because they are not XML or JavaScript):
>
> PHP (PHP calls all collections of elements arrays, whether they are indedxed or not)
> $hash = array('z' => 1, 'x' => 'c');
> foreach ($hash as $key) {
>      print "hash[$key] = $hash[$key]\n";
> }
>
> hash[x] = c
> hash[z] = 1
>
>
> on conversion to Perl and using the code before for display
>
> Perl
> # Create data the same way as PHP
> my $hash = {'z' => 1, 'x' => 'c'};
> foreach (my $key keys(%hash)) {
>      print "hash{$key} = $hash{$key}\n";
> }
>
> hash{z} = 1
> hash{x} = c
>
>
> If the order of items is important, than an indexed array MUST be used.

Given that strict ordering is not 100% possible, we are currently trying to maximize ordering and partial ordering without

> This does go back to a point I raised earlier. By creating data elements in JSON for the XML comments, you are changing the data model stored in the file. Things that were not data nor parsed (XML comments) are now appearing as data. It also means that full-escaping and character translating to the allowed JSON character set must be done to ensure that the result can be parsed in JavaScript. You are trying to create something that does not exist in the language (comments). I feel that this is not the right way to go.

Although comments are not defined in JSON specification, they are supported in the parent JavaScript language and in the related JSON5 work that Cecile recently exposed for everyone.

Comments are also supported in VRML97 as well as the ClassicVRML, XML, and Compressed Binary Encoding (CBE) for X3D.  Each of the 4 specifications defines how they are handled.  They are also included in the tables of the H-Anim specification.

Our defined X3D JSON design goal is to provide the best possible round-trip conversions to other X3D encodings.

The X3dToJson.xslt conversion stylesheet does not require inclusion of comments and allows stripping them.

We are definitely trying to maximize preservation of content while being efficient and correct, so that the X3D JSON encoding eventually gets the broadest possible use.

At some point we might do well to write up the small differences in comment handling that exist between X3D encodings.  For example, common practice in VRML97/ClassicVRML allows putting comments within numeric arrays, while that is not allowed in XML or compressed binary encodings.  Perhaps a suggested 1-way mapping should also be suggested as a best practice when such conversions are needed.

Again thanks, additional considerations regarding comments are always welcome.

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