[x3d-public] X3D JSON Schema Updates: determining event constraints forSFTimedurations and timestamps

John Carlson yottzumm at gmail.com
Mon Apr 16 01:28:10 PDT 2018

I don’t see XvlShell under the 3.0 object model.  Will you remove it from the JSON examples?


Sent from Mail for Windows 10

From: John Carlson
Sent: Sunday, April 15, 2018 11:59 PM
To: Don Brutzman
Cc: X3D Graphics public mailing list; X3D Graphics member mailing list; npolys at vt.edu
Subject: RE: X3D JSON Schema Updates: determining event constraints forSFTimedurations and timestamps

Don’t forget XvlShell and @headlight under the Object Model 3.0 (I will check).


Sent from Mail for Windows 10

From: Don Brutzman
Sent: Sunday, April 15, 2018 11:02 PM
To: John Carlson
Cc: X3D Graphics public mailing list; X3D Graphics member mailing list; npolys at vt.edu
Subject: Re: X3D JSON Schema Updates: determining event constraints for SFTimedurations and timestamps

[John: minor annoyance, dueling mailer issues.  When i Reply using plain text to your MS-html email, it seems like the indentation styles get lost and it is very difficult to say who is saying what...]

[I will try to remove or re-indent any prior parts so that the result might be intelligible.  Hope that works.]

On 4/15/2018 3:56 PM, John Carlson wrote:
> On Sun, Apr 15, 2018, 4:47 PM Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu>> wrote:
>>     This email thread gets the ball rolling (or perhaps the clock ticking!)... we will need an X3D Working Group call to tackle this topic and look at SFTime issues/actions.
> Let's see if other people chime in.

>>     ==========================
>>     5. Next, regarding X3D JSON Schema.
>>      > Normally, I copy the 3.3 JSON schema to 3.0, 3.1, 3.2 and 4.0, so that will be what I do.  If this is drastically different than previous schemas for those versions, let me know.  I don’t know what I’ll do, but at least I’ll know.

I think that you can safely avoid copying and safely avoid worrying about versions.  Wait until we autogenerate earlier versions if you want to be strict.

In the meantime, the version 3.3 JSON schema should work on all X3D models version 3.0 through 3.3 since we are always so careful about backwards compatibility between versions.  Note that each schema validation of X3D element allows prior version numbers.

If using 3.3 for all scenes all the time does lead to any problems with JSON validation, please let me know so that we can fix it.

>>     You can see all the variations corresponding to X3D versions in the specification itself:
>>     X3D Abstract Specification,  Annex Z (normative) Version content
>>     http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/versionContent.html
>>     So yes there are a lot of differences.  Each time we get modifications to X3D XML DTD or Schema it usually takes me maybe two hours to carefully apply diffs from X3D v3.3 to versions 3.0, 3.1, 3.2 and 4.0 then update documentation.
> Okay, perhaps it is time to start generating the other versions for the X3DUOM.
>      > I think it’s best to autogenerate these schema fields as snippets from the X3DUOM and upgrade the JSON schema by using autogenerated snippets.    It appears according to the standard that many of these fields are new ones. Plus snippets are less error prone.   So let’s get them into the object model soon.
> It looks like some already are?

Yes, changes in the X3D XML schema go into the X3ObjectModel3.3.xml and then into X3DJSAIL, where they get tested.  So all of the SFTime duration changes are there.

>>     Agreed, that is getting onto my long-range radar... autogenerating JSON Schema via XSLT stylesheet will be an excellent test of X3D Unified Object Model, and prose/links i that page are now updated online as well.

> Please do not spend time on this.  It's more important to get more versions of the object model.
>>     X3D Unified Object Model (X3DUOM)
>>     http://www.web3d.org/specifications/X3DUOM.html
>>     Extra-credit issues:
>>     a. generating X3DObjectModel-3.3.xml files for each X3D version
>>     http://www.web3d.org/specifications/X3DObjectModel-3.3.xml

> That's your task, Don, or someone who is familiar with your builds/Xslt.

OK, can do... worked today on the build scripts and generation stylesheet.

Have renamed several files for better clarity (earlier deferred with Roy) and improved the processing, creating a new object-model file directly, version by version, from each corresponding X3D schema.

And so added corresponding matches as follows:

                http://www.web3d.org/specifications/X3dUnifiedObjectModel-4.0.xml (experimental)
                http://www.web3d.org/specifications/X3dUnifiedObjectModel-3.3.xml (primary)
                http://www.web3d.org/specifications/X3dUnifiedObjectModel-3.2.xml (strict backwards compatibility)
                http://www.web3d.org/specifications/X3dUnifiedObjectModel-3.1.xml (strict backwards compatibility)
                http://www.web3d.org/specifications/X3dUnifiedObjectModel-3.0.xml (strict backwards compatibility)

All of these links are now refreshed, committed and online via

                X3D Unified Object Model (X3DUOM)

>     b. both X3DJSAIL and X3DJSONLD may have enough information embedded already to generate matching JSON schemas.
> Yes, given an X3DUOM file, I should be able to create a python script or shell script which generates the JSON schema for each version with some slight modifications (commandline parameters).   We just need the X3DUOM files and a bit more testing validation of the JSON schema.  That already exists (My 5.0 and 5.1 schemas I posted).

Agreed.  Not sure we want that, but it might be interesting task to confirm that round-trip of all unified object model information is available + possible from our implementations.

> Unless of course, you want to create the mother of all X3DUOM files and put all the versions in one file.   We can certainly do that, but I will still probably separate out the JSON schema versions.

Thought about that, but no (or maybe Good Lordy No!!) since it adds yet another layer of complexity without apparent benefit.  Keeping each version independent is cleaner and more repeatable.

Plenty more to follow, meanwhile...

Have fun with the X3d Unified Object Model!  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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180416/82ad8fd4/attachment-0001.html>

More information about the x3d-public mailing list