[x3d-public] Check -prototype- parameters for range, enum, what else? call for IMPORT/EXPORT examples

[Don Brutzman]

Great analysis Joe.

I think we have excellent support in all of our prototype validation tools for all the many quality assurance (QA) tests that are appropriate.

We also have many examples throughout the X3D Examples Archives that exercise these checks.

APIs like X3DJSAIL and others can further apply checks during the construction and subsequent validation of a prototype set (declaration and instancing) to alert whenever difficulties arise.  I'd rate support as good and improving, will be adding such patterns to x3d.py library as well.

Strong typing is what makes X3D prototypes a first-class capability for X3D language extensions (i.e. new author-created nodes).  We should keep taking advantage of that.

Support for IMPORT/EXPORT is currently superficial.  Unlike prototypes themselves, we don't have any models to test in the X3D Example Archives.

Who has good IMPORT/EXPORT scene pairs that can be placed in the open-source archives?  This will only become even more important as we begin to Inline glTF models and then IMPORT/EXPORT values from the glTF, as Castle Game Engine has already reported doing.

Good examples drive... everything, they are how we can achieve implement/evaluate testing.  Let's get some good IMPORT/EXPORT examples that show this important capability.


On 6/18/2020 6:06 PM, Joseph D Williams wrote:
>   * Also note that ProtoInstance is acceptable anywhere a node is acceptable, further type checking (i.e. is that an acceptable ProtoInstance?) has to occur in the library - usually the setter is a good place for that.
> 
> Important is that we are able to check types at authortime. With xml schema it is possible to do that for spec nodes using the spec schema. For prototype definitions it id desired that the xml authortime tool augment the spec schema by perhaps generating an equivalent prototpe instance schema for each prototype; for reuse validating the instance?
> 
> It is not unusual to use several different prototypes and several instances of the same prototype. Anyway, It is nice to be able to troubleshoot some prototype instance placement in the hierarchy and simple checks for appropriate field values without having to run the things. Of course a dedicated author might do this manually, but it would also be handy to have this as some level of convenience for some level of authoring system.
> 
> I think this might also be a solution to the rather,  as I read it,  clumsy legacy appearing user code now required for xml prototype instances. If we have a schema instance for the proto instance, then we have complete authortime validation, at least. And, instance can then look like a usual node in the user code courtesy of the augmented schema.
> 
> Maybe a deep reason that html doesn’t know about structures like prototypes. Can’t allow a ‘live’ schema!
> 
> Thanks,
> 
> Joe
> 
> *From: *Don Brutzman <mailto:brutzman at nps.edu>
> *Sent: *Tuesday, June 16, 2020 6:37 PM
> *To: *John Carlson <mailto:yottzumm at gmail.com>
> *Cc: *X3D Graphics public mailing list <mailto:x3d-public at web3d.org>; Peitso, Loren (CIV) <mailto:lepeitso at nps.edu>
> *Subject: *Re: [x3d-public] Check parameters for range, enum,what else? TypeScript?
> 
> Yes stick with primary types first.  Then do Field types: SFFloat, SFVec3f, etc.  Then look at overloading with convenience methods/constructors, each programming language varies in that respect.
> 
> On 6/15/2020 8:14 PM, John Carlson wrote:
> 
>  > I am checking parameters for range, enum, length, not type(s) yet, ... what else is there for setter and constructor parameter checking?
> 
>  >
> 
>  > My first gulp would be to give parameters to their types, ala TypeScript.  That would be one way to solve the parameter type problem. Is it OK to convert my ES6 x3d.mjs module to TypeScript? Those who are against the coffee languages might approve.
> 
>  >
> 
>  > I can see that the X3DUOM supports multiple types for parameters.
> 
> for most fields it actually is no, X3DUOM only gives a single primary type for basic (non-node) types.
> 
> For content model, sometimes it is a mix of node types and nodes that are acceptable in an SFNode/MFNode field  Also note that ProtoInstance is acceptable anywhere a node is acceptable, further type checking (i.e. is that an acceptable ProtoInstance?) has to occur in the library - usually the setter is a good place for that.
> 
> Looking at X3DJSAIL Java (Javadoc or source) and x3d.py will give examples for each and every case that you can use as exemplars to check your patterns.  They will likely be the same, just expressed a bit differently in each language.
> 
>  > It looks like TypeScript allows overloading as well.
> 
>  >
> 
>  > Thanks,
> 
>  >
> 
>  > John
> 
> Doing TypeScript as a more rigorous/debuggable path to get towards EcmaScript certainly sounds appealing, as Cecile describes.
> 
> Hope you aren't feeling faint of heart - but it does aggregate nicely as you produce autogeneration patterns.
> 
> Good luck out there!!  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
> 
> _______________________________________________
> 
> x3d-public mailing list
> 
> x3d-public at web3d.org
> 
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> 

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