[x3d-public] X3D JSON Schema warnings and validation automation progress

[Don Brutzman]

Roy, your new X3D JSON Schema itself passes without the --white switch:

> ant -f C:\\x3d-code\\www.web3d.org\\x3d\\stylesheets test.X3dToJson.xslt
> test.mkdir:
> test.X3dToJson.xslt:
> =====================================
> First check X3D JSON Schema:
> ..error checking with jslint
> ..error checking with json-schema-validator
> --- BEGIN C:\x3d-code\www.web3d.org\specifications\x3d-3.3-JSONSchema.json---
> validation: SUCCESS
> --- END C:\x3d-code\www.web3d.org\specifications\x3d-3.3-JSONSchema.json---
> =====================================

The handful of additional test scenes in the X3D Stylesheets project all pass too.  And so your version-control changes are now updated online as well:

	http://www.web3d.org/specifications/x3d-3.3-JSONSchema.json

I will publish an update to all schemas and re-run JSON regression tests to ensure no surprises crept in.

On 3/27/2016 10:21 AM, Roy Walmsley wrote:
> Don,
>
> A little research revealed it was all too easy to convert tabs to spaces. Or even, if you prefer, to remove white space altogether!

suggest readability as the guiding principle, which probably means simple whitespace.  clarity leads to correctness.

download size reduction due to whitespace isn't really a factor since http: includes date/time checks and avoids repetitious downloads.

> So, I have just committed a new version of the schema. I made the following three changes:
>
> 1) Made profile and version both required attributes of the X3D object
> 2) Made X3D, head, and Scene objects all global definitions
> 3) Converted all tabs to spaces (I hope!)
>
> Let me know how it looks.
>
> Roy
>
> -----Original Message-----
> From: Don Brutzman [mailto:brutzman at nps.edu]
> Sent: 27 March 2016 17:52
> To: Roy Walmsley
> Cc: 'X3D Graphics public mailing list'; 'John Carlson'
> Subject: Re: X3D JSON Schema warnings and validation automation progress
>
> On 3/27/2016 5:36 AM, Roy Walmsley wrote:
>> Don,
>>
>> I'm assuming that the tabs were added automatically by XMLSpy, as I generated everything graphically. When I do the auto-generation (and I'm starting to think about that now) I'll ensure that I use spaces, not tabs. In the meantime, are you happy to continue with the --white command line switch?
>
> Whitespace can be a tricky business in JSON.  Douglas Crockford is very assertive over what he thinks is best and does not hesitate to impose that unilaterally in jslint.  In part this is motivated by javascript tool pathologies, not just perceived coding style.  I found several places where people disagreed with his whitespace rules and disliked that there was not finer-grained control to ignore some aspects (e.g. allow tabs instead of space characters).
>
> 	http://jslint.com
>
> In addition to detailed explanations of rules and relaxations, he politely warns people that they may get really upset.
>
> http://jslint.com/help.html
> =================================================================================
> [...]
>> Please let me know if JSLint is useful for you. Is it too strict? Is there a check or a report that could help you to improve the quality of your programs? douglas at crockford.com. But please don't ask me to dumb JSLint down or to make it more forgiving of bad practices. You would only be disappointed.
>>
>> I intend to continue to adapt JSLint based on your comments. Keep watching for improvements. Updates are announced at https://plus.google.com/communities/104441363299760713736.
> [...]
>> Perfectly fine
>>
>> JSLint was designed to reject code that some would consider to be perfectly fine. The reason for this is that JSLint's purpose is to help produce programs that are free of error. That is difficult in any language and is especially hard in JavaScript. JSLint attempts to help you increase the visual distance between correct programs and incorrect programs, making the remaining errors more obvious. JSLint will give warnings about things that are not necessarily wrong in the current situation, but which have been observed to mask or obscure errors. Avoid those things when there are better options available.
>>
>> It is dangerous out there. JSLint is here to help.
>>
>> Warning
>>
>> JSLint will hurt your feelings. Side effects may include headache, irritability, dizziness, snarkiness, stomach pain, defensiveness, dry mouth, cleaner code, and a reduced error rate.
> =================================================================================
>
> The jshint project appears in some part motivated by these differences in opinion.  They further warn that turning off jslint whitespace checking will allow some problems to pass through.
>
> 	http://jshint.com
>
> Recommendation: as usual, let's be "strict about what we produce and lenient about what we accept."  So for X3D JSON Schema, and X3dToJson.xslt conversion outputs, let's work to match the strict (no variation) whitespace rules that jslint advocates.  That way anyone else using these X3D products doesn't have to worry about whitespace at all.
>
> If XML Spy lets you clean up schema whitespace in that fashion, then great.  I can then remove the "--white" command-line switch.  If it doesn't have that option, then let me double-check with you and then we can submit an issue report to them for future improvement.
>
> If the whitespace issue is at all difficult or time-consuming to fix, then let's leave it alone and address the problem later when we begin to autogenerate the X3D JSON schemas, version by version, from the X3D XML Schema-generated X3D Object Model.
>
> Best-case scenario: we eventually pass all validation tools without hiccups.
>
>> Great work with the validation!
>>
>> Regards,
>>
>> Roy
>
> Thanks again Roy for the super job on the X3D JSON Schema, another big step forward for all of us.  8)

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