[x3d-public] X3D JSON schema, identifying element type for items within an array.

[John Carlson]

Decision should be made whether array X3D type to array item X3D type 
map should be in X3D JSON schema generator or X3DUOM.

As discussed in our meeting today, I am adding a $comment with X3D type 
before "type": occurs in the X3D JSON schema.

This will require more work than initially required, although the 
changes so far have been fairly straightforward in the somewhat messy code.

For example:

              "@url": {
                "pattern": "^(\\s|\\S)*$",
+              "$comment": "X3D type: MFString",
                "type": "array",
                "minItems": 1,
                "items": {
                  "format": "uri-reference",
+                "$comment": "X3D type: MFString",
                  "type": "string"
                }
              },


The X3D type for the items object, should be SFString one would think.   
So I'll have to check to see if I'm in an array.

Probably by looking for "items".  Then I'll look for MF in the field 
type, and replace the first M with an S.


But here are added problems looking at arrays:


              "@bboxSize": {
                "pattern": 
"^\\s*(([+-]?((0|[1-9][0-9]*)(\\.[0-9]*)?|\\.[0-9]+)([Ee][+-]?[0-9]+)?)\\s+){2}([+-]?((0|[1-9][0-9]*)(\\.[0-9]*)?|\\.[0-9]+)([Ee][+-]?[0-9]+)?)\\s*$",
+              "$comment": "X3D type: SFVec3f",
                "type": "array",
                "minItems": 3,
                "maxItems": 3,
                "items": {
                  "default": -1,
+                "$comment": "X3D type: SFVec3f",
                  "type": "number"
                }
              },


In this case, the SFVec3f would be found, and a mapping between SFVec3f 
to SFFloat for individual items should be made.

So perhaps a simple map could be constructed which maps array type to 
item type.


Does this sound pretty feasible, essentially a hard coded map from array 
type to item type in the generator code?

I will look for additional issues now.  I'm not seeing much right away.  
I know I ignore some of the "type" fields right now, particularly in 
hard coded definitions.

Note that I'm inserting documentation.  This shouldn't affect the 
running of the generator.

My main question is, where does the information reside?  Should it be in 
X3DUOM?

Does anyone mind if I start calling my generators "synthesizers"?  I'm 
on a new kick!

Note that we are moving towards XSL for our primary JSON schema 
synthesizer, lessening requirements on future maintainers.   We're 
currently using python to suss out patterns and requirements for 
X3DUOM.   The python pretty much is impossible to maintain (even the guy 
that wrote it admits that).  If you know any "younguns" who love XSL, 
encourage them to join and contribute to X3D!

Building holistic schema synthesizers.

My next job will be to build holistic spaceship synthesizers.

If anyone wants to write a validator which validates the X3D JSON 
schemas against X3DUOM, that would be WAY cool!

In my dreams,

Johnnyhehehe