[x3d-public] x3d.js big, X3D4 JSON schema big, can we reduce size?

[John Carlson]

I am fairly sure that JSON schema does not have inheritance, thus the need
to share definitions.   In other words, interface nodes at the interface
level are are not defined.    I agree that looking at interfaces would be a
good way to find shared fields.

I’m just not sure which of my X3DUOM parsers ignore abstract types, and
whether abstract types are ignored in field types.  I do think abstract
types are required for fields.   I think that there are 2 composite types
for JSON, object and array.   This goes for JSON schema as well.   I
learned most about JSON schema by reading Roy’s schema, however.

The whole beauty of JSON is that it takes data structures to the core and
only offers objects, arrays and primitives.   In some ways, it resembles
Scheme, Lisp and DOM.
Yes, I agree that typesafety is good.   Extensibility and flexibility are
good too.   There are two levels, parsing and semantics.   We want easy to
parse structures for both machines and humans.   Then we layer semantics
and validation above that.

I don’t want to copy Charles Petzold’s CSAML. Operations or behavior are
better defined another way.  I think that is one reason why I brought up
specification languages (there’s one that’s an ISO standard).

Animation fits nicely between the two, you can have declarative or
behavioral (might save space) animation.   I think moving behavioral
animation into declarative animation is a good thing.

Most of my current animation is behavioral, and I welcome discussions on
how to make it declarative (that’s why I am here, I think).   My guess is
that it may fit best in a particle system.  In the real world, it probably
fits best with a self-driving car...how do we animate that declaratively?

John

On Mon, Apr 5, 2021 at 1:37 AM John Carlson <yottzumm at gmail.com> wrote:

> I am not really sure how to parse X3DUOM without a “do it all at once”
> mindset.   The point is, we now want to work on reuse.
>
> The big question is, when field names are reused, do they have the same
> type?  For @rotation, there were different types.
>
> It will be important to keep track of definitions so they can be
> rereferenced.
>
> I agree we should design the schema before mass producing them.   I
> attempted to follow Roy’s lead, but fell down when it came to reuse in some
> cases.
>
> John
>
> On Mon, Apr 5, 2021 at 12:31 AM Don Brutzman <brutzman at nps.edu> wrote:
>
>> John, compression is likely useless because we can't develop a schema if
>> it is encoded in binary.
>>
>> The key to making such a schema smaller lies in whether JSON Schema is
>> object oriented or not.
>>
>> If object oriented, then all of the shared strongly typed field
>> information doesn't have to appear multiple times.
>>
>> X3DUOM includes the entire X3D inheritance hierarchy so this can be
>> automated.
>>
>> After searching I think the descriptions you seek can be found at (of all
>> places) the JSON schema documentation:
>>
>> * Understanding JSON Schema 7.0, Structuring a complex schema
>>
>> https://json-schema.org/understanding-json-schema/structuring.html#structuring-a-complex-schema
>>
>> Again the key here is to not perform brute-force heroics on a gigantic
>> schema by hand.
>>
>> Instead make a series of JSON schemas of gradually increasing expressive
>> power that validate something extremely simple, like HelloTriangle.json or
>> Hello World.json models.
>>
>> * X3D Example Archives: X3D4WA, X3D for Web Authors, Chapter 01 Technical
>> Overview, Hello Triangle
>>
>> https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter01TechnicalOverview/HelloTriangleIndex.html
>>
>> https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter01TechnicalOverview/HelloTriangle.json
>>
>> https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter01TechnicalOverview/HelloTriangle.x3d
>>
>> On 4/3/2021 10:56 PM, John Carlson wrote:
>> >
>> > I think we can make some effort to reduce the size of the X3D JSON
>> > auto-generated schema (especially 4.0).  There is a lot of duplicated
>> > stuff there, I think.
>> >
>> > We can look to Roy's schema for inspiration, likely.
>> >
>> > es6x3d/x3d.js grew by an order of magnitude just by sitting there.  I
>> > think it's too big now.
>> >
>> > Is there an optimizer person available?
>> >
>> > Thanks!
>> >
>> > John
>>
>> 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/20210405/9e831050/attachment.html>