[x3d-public] XML Validation in browser, JSON validation in browser, SAI validation, TypeScript SAI

[John Carlson]

>From what I gather, XML/DOM document validation is not often done in a web
browser, except with some very old Microsoft tools.  Now I understand why
we want JSON, it's very validateable in JavaScript on the browser.  This is
important for static sites, or for validation of text strictly within the
web browser (no post back to server, so people's documents don't get
uploaded).

Here's a recent discussion on ECMA standardization of JSON schema.  Voices
from the community need to be heard.  Apparently, there's some discussion
of a new technical committee.

Proposal: JSON Schema Standardization under Ecma International ·
json-schema-org · Discussion #938
<https://github.com/orgs/json-schema-org/discussions/938>

So the real question is, do we validate with Schema, or a SAI?  If we
validate with SAI, we don't need schema.  What do you think?  I think we
can leverage SAI generators to validate, like X3DJSAIL and X3DPSAIL, the
question is, will people take advantage of SAI validation templates?  I'm
looking at X3DOM and X_ITE/Sunrize here.

I can probably copy X3DJSAIL to produce a JavaScript/TypeScript SAI, I
realize people have been wanting one.  The question is, can I support
multiple renderers?  Would people prefer the X3DOM SAI, the X_ITE SAI, or
something like Three.js, PlayCanvas or Babylon..js? or all of the above?
Three.js already supports several renderers.  I need an architect/designer
if I'm going to front several backend engines.

Note: Three.JS supports these renderers in addition to WebGL and WebGPU:

CSS3DRenderer SVGRenderer, CSS2DRenderer

Note that I would prefer NOT to handle a bunch of `to XML`, `to JSON`, `to
VRML` to an API.  But things like `to X3DOM`, `to X_ITE`,  `to THREE` etc.,
is looked upon favorably.  If we can create a layer that will import the
core libraries upon demand, that seems a win for everyone.  This might be
equivalent to ANARI's plug in device library for raytracing examples.

No, I am typically against "Yet another standard."  We will work to evolve
any pre-existing X3D JavaScript standards towards a typesafe TypeScript
standard.

Thanks,

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20260228/75f2ab1b/attachment.html>