<div dir="auto">Currently, I use the @rotation from Roy’s JSON schema everywhere in the generated schema except TextureTransform.</div><div dir="auto"><br></div><div dir="auto">Not checked in, sorry.</div><div dir="auto"><br></div><div dir="auto">John </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 1, 2021 at 10:31 PM John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">A.4 action items in email. We probably should track tasks in the JSON <br>
project in Mantis (TODO).<br>
<br>
A.5 complete. Used donall.sh from X3DJSONLD to generate JSON. Inform <br>
John when new JSON download zip is available.<br>
<br>
A.6 is next work task.<br>
<br>
Updates to Roy's hand-generated JSON schema is top discussion priority. <br>
John already has some changes.<br>
<br>
Discussion of @geoSystem "N"orthern Hemisphere. Squaw example still <br>
has many examples. There are 90 problems in data with @geoSystem. <br>
Suggest we take "N" out with X3dToJson.xslt<br>
<br>
We need to discuss @rotation subschema in X3D JSON schema. Roy's schema <br>
has ranges, which creates 1800 errors when running through the X3D <br>
resources examples. These appear in Everit, but haven't found them in <br>
Ajv yet. See A.6.<br>
<br>
On 3/30/21 9:08 PM, John Carlson wrote:<br>
> Note, A.1 first half is complete. Progressing with A.4.<br>
><br>
> A.<br>
><br>
> 1. We will work towards testing the X3D JSON Schemas with draft-07 of <br>
> the JSON Schema (one of the widest implementations of JSON Schema, and <br>
> most recent one for Python). This will be our primary short term <br>
> type-checking mechanism beyond X3DJSAIL-X3DJSONLD and x3d.py. (other <br>
> type-safe mechanisms appear to be burdensome for entire X3D standard, <br>
> investigations into profiles welcome).<br>
><br>
> 2. We will investigate JSON 5, but we see no reason to support <br>
> something which is not even on a standards track when our current <br>
> tools are focused on the JSON schema RFCs. Is there a JSON 5 schema?<br>
><br>
> 3. XMLSpy is an important tool for JSON.<br>
><br>
> 4. We will test draft-07 based X3D JSON generated schemas and the <br>
> hand generated schema (draft-06?) against each other in the JavaScript <br>
> environment.<br>
><br>
> 5. We will support the Java everit JSON validator with draft-07 <br>
> schema, and test it. John will run everit code against the JSON <br>
> examples in the archives.<br>
><br>
> 6. We will attempt to resolve differences between JavaScript and Java <br>
> validators, make contacts with JSON schema validator source code <br>
> authors to ensure equivalent errors are reported.<br>
><br>
> 7. We will likely finish the X3D JSON encoding standard (but that <br>
> wasn't mentioned in meeting today).<br>
><br>
> 8. We will continue to support auto-generating the X3D JSON schemas, <br>
> versions 3.0-3.3, and 4.0.<br>
><br>
> Note that we have packages for JSON -document to DOM document we can <br>
> test, including X3DJSONLD.js (found in X3DOM, X_ITE and X3DJSONLD), <br>
> X3DJSONLD.java (found in X3DJSAIL source code), and X3DJSONLD.cpp <br>
> (standalone, source code available in X3DJSONLD, binaries for Kubuntu <br>
> Groovy Gorilla available). Further languages are upon request. <br>
> These modules take JSON and produce a DOM document.<br>
><br>
> B. After that:<br>
><br>
> 1. We will support the X3D SAI update with feedback from the <br>
> ECMAScript/TypeScript community (Andreas, can we count on you to help <br>
> on X3D SAI standard feedback for JavaScript? I'm thinking of your <br>
> X_ITE DOM code which I have not analyzed or even looked at).<br>
><br>
> 2. If there is demand, we will write/generate a typesafe ECMAScript <br>
> SAI based on X3D SAI and use similar patterns to other X3D language <br>
> bindings.<br>
><br>
> 3. If there is demand, we will modify the generator in item B.2 for <br>
> the ECMAScript SAI to create a TypeScript SAI (funding required, GSoC?).<br>
><br>
> 4. We will watch to see what 3D TypeScript libraries become important <br>
> and figure out if we can support them with X3D JSON import/export. <br>
> Likely of all things, this is the most important for X3D adoption in <br>
> ECMAScript/TypeScript. Watch for more developments in and beyond <br>
> Three.JS, PLY and STL in the X3DJSONLD package. Thus after JSON <br>
> standardization, this will likely become John's highest priority. <br>
> Similar to how Michalis has converted formats to X3D, I want to <br>
> support dispersion of X3D JSON to many <br>
> ECMAScript/JavaScript/TypeScript 3D libraries and more programming <br>
> languages beyond Java, JavaScript and Python. We will use Don's <br>
> X3dToJSON.xslt to provide a bridge between Michalis' code and my code <br>
> (unless some other ECMAScript translation from X3D to JSON suddenly <br>
> appears).<br>
><br>
> ============================================<br>
><br>
> C. I am interesting in hearing about possible X3D JSON extensions for <br>
> newer shading languages coming out. What shading languages are <br>
> supported in glTF? Do they support raytracing? I don't have a <br>
> raytracing card yet. I am considering upgrading Mac Mini.<br>
><br>
> D. We do not see on the fly modification of JSON necessary except for <br>
> Protos and Scripts (consider source JSON immutable). Those should <br>
> be supported by the X3D browsers, not X3DJSONLD. X3DJSONLD has an <br>
> example Script preprocessor, but it's pretty much deprecated in favor <br>
> of X_ITE's example.<br>
><br>
> Be excellent to each other!<br>
><br>
> John<br>
><br>
</blockquote></div></div>