[x3d-public] X3D Java SAI. Declarative style

Joe D Williams joedwil at earthlink.net
Sun Jan 22 03:53:44 PST 2017


Well, it just goes on to show that two widely unacknowledged details 
about VRML/X3D with abstract, concrete, scripted, and prototyped nodes 
in totally determinant object and event structures is:
First, its nD+1 functional structure can be implemented in any 
language or formulation that can represent interactive shared 
multidimensional reusable realtime scenegraph hierarchies in human 
editable form.
Second, its time- and event-driven realtime anytime event graph 
represents an interactive system to reliably direct and capture single 
or groups of instantanous events for a specific time simulation, in a 
sequence of specific time simulations.

So, however it interacts with, directs, and documents your perceptual 
apps above and under the covers, in which choice formulation it is 
presented to the user, if whatever it is can be somehow be validated 
using our web3D extensible X3D object model and runtime references, 
then you actually really do have real X3D.

Thanks and Best,
Joe



----- Original Message ----- 
From: "Don Brutzman" <brutzman at nps.edu>
To: "John Carlson" <yottzumm at gmail.com>
Cc: "Joe D Williams" <joedwil at earthlink.net>; "X3D Graphics public 
mailing list" <x3d-public at web3d.org>
Sent: Saturday, January 21, 2017 10:31 PM
Subject: Re: X3D Java SAI. Declarative style


> cc: list for others interested in the journey, now or in the future.
>
> [... continuing response to remaining helpful email points in prior 
> round ...]
>
>> On 1/19/2017 2:17 PM, yottzumm at gmail.com wrote:>
>>>> [...]
>>>
>>> Joe wrote:
>>>
>>> So that it is the current data structures being advanced move 
>>> toward
>>> data storage in forms convient for the back end rather than human
>>> readability or functional groupings ...  more toward machine
>>> convenience, to me, kind of like the direction of vulcan and xflow
>>> definitions. This gives certain advantages of reusability, 
>>> perhaps,
>>> but usually means that a basic human-readable form is unlikely or
>>> needs a highly level editing tool.
>>>
>>> I do not see the new Java SAI document “encoding” as being 
>>> standardized or something that a high level editing tool or back 
>>> end will **consume**.  And that is important here.  We could build 
>>> something that would take ANY Java and produces a scene graph, 
>>> simply by printing out the X3D object at the end.  The point here 
>>> is that both techniques generate a scene graph.
>
> Correct.  Please note that (among other things) the X3DJSAIL library 
> provides interfaces for, and conforms with, the existing SAI 
> specification.
>
> Some small clarifications to that specification which arose out 
> implementation testing are being submitted for working-group 
> consideration and listed at
>
> Specification Changes under Consideration
> http://www.web3d.org/specifications/java/X3dJavaSceneAuthoringInterface.html#SpecificationChanges
>
> * X3dJavaSpecificationChangesAndIssues.txt lists noted problems with 
> the governing specification X3D Java SAI Language Bindings (ISO/IEC 
> 19777-2).
> * Specification prose is needed to define necessary support for DEF, 
> USE and class attributes.
> * Consider appropriate specification issues for abstract SAI and 
> corresponding encoding specifications.
> * Not needed: adding Annex D Java SAI Concrete Classes for 
> standalone scene programming, since other approaches can be 
> accomplished compatibly.
> * Mantis issue tracker keeps track of details, alternatives and 
> resolution for each specification issue.
> * Web3D Consortium github (member-only access) is used to maintain 
> editors-draft Web3D specifications in version control.
>
> There are also some relatively minor X3D Object Model issues to sort 
> out for consistency amongst all SAI language implementations.
>
> X3D Object Model issues for review
> http://www.web3d.org/specifications/java/X3dJavaSceneAuthoringInterface.html#TODO
>
> * In progress. Implement specialty string subtypes such as ID, 
> IDREF, NMTOKEN and NMTOKENS.
> * Decide how to represent contained CDATA source code for Script and 
> Shader nodes.
> * Document how ROUTEs and comments can be children of nodes and 
> statements (but not on a per-field basis).
> * Confirm consistent handling of ROUTE, ProtoInstance, ProtoDeclare, 
> ExternProtoDeclare. Ensure that specification support for 
> ProtoDeclare and ExternProtoDeclare includes appinfo and 
> documentation fields. Ensure that specification support for 
> ProtoInstance includes DEF USE IS class and metadata fields.
> * Provide annotation descriptions for abstract node types in XML 
> Schema.
> * Finish X3D Regular Expressions (regexes), apply them in X3D XML 
> Schema, then include in X3D Object Model.
>
>>  I view the PRIMARY purpose in developing a style to 1) test the 
>> SAI 2) provide an example for developers+.
>
> yes, an example implementation.  cleaner than others in the past.
>
> others may occur in the future - that's OK, vive la difference. 
> nevertheless am calling X3DJSAIL a _Library_ in the hopes that we 
> continue to optimize it and add much further functionality for 
> applications:  XML security, compression, conversion to/from various 
> formats, optimizers, etc. etc.
>
> feature wish list continues in the TODO link above.  contributions 
> welcome.
>> I think a cross between the two styles is the best approach—like 
>> defining variables for each node and not reusing the variable for 
>> setting attributes, but perhaps generated Java is not good at 
>> expressing a cross (know a language that does?  Scala?)?
>
> Seems like Scala and a few other modern languages (some of which 
> actually compile to Java bytecode) have had a positive and 
> significant influence on the current evolution of Java itself.
>
>>  Something like JSON or XML would be better.  I think Don is merely 
>> highlighting that the Declarative/Functional approach is better, 
>> and I don’t disagree with him.
>
> Correct.  We get both older and newer styles of programming with 
> Java 8.  The X3DJSAIL library is being designed for compatibility 
> with both approaches.
>
>> However, I think it may be problematic achieving his goals, and to 
>> do purely may require some getParent() routines to do right, which 
>> we should consider whether we should add a parent reference to many 
>> objects or not.  Otherwise, we are still storing variables. (I 
>> think the getParent() may also break down the gains earned by 
>> parallelism, but don’t quote me on it).  That is, we can either 
>> store the variables inside the objects or outside the objects. 
>> Data hiding leads us to want to store them inside the object, I 
>> just don’t like the security implications of a child (subclasses) 
>> being able to access the parent environment.
>
> Yes agreed these are worthy concerns.  Testing will tell.  The book 
> indicates that this style lets Java automatically figure out which 
> subblocks can be parallelized.  And in any case it can't be any less 
> optimizable than less-structured Java source.
>
> I expect that the key to support for modular parallelizable blocks 
> when "walking the graph" with methods like getParent() 
> findElementByName() findNodeByDEF() will be to keep them local to 
> other code where they are needed.
>
> Also of note: this parallelism might help with really big files, 
> working offline or on a server.  Such improvement not expected 
> within Script nodes, they are tied to the event loop and 
> rendering/interaction loop.
>
> So it appears that we are in a new and wonderful design space for 
> Java applications and other Java frameworks, actually.  Hence 
> multiple loose similarities to node.js server engine (for standalone 
> browser-less javascript).
>
>>> If I am testing the SAI, I should test it in all ways that humans 
>>> will use it.  Don first proposed one method, which I followed 
>>> along with.  Then Don proposed another method, which I haven’t 
>>> signed off on, at least until he solves the addChildren/getParent 
>>> issue.
>
> just released in preceding announcement.  thanks for scrutiny, 
> constructive criticism and resulting improvements!
>
> There is still some more work to do on addChildren pipelining, stay 
> tuned.  Am expecting to add another utility method that sidesteps 
> the emergent limitations of the Java SAI addChildren interfaces.
>
>>  We do need a way to debug the SAI, and if my technique is 
>> hindering us from debugging or developing the SAI, that should be 
>> made better known.
>
> i am able to use Netbeans debugger OK.  also the just-released 
> examples show tracing of results into comments (for persistence), 
> could have also sent results to console.
>
> So that might be slightly different than before, but not by very 
> much, and remains excellent.
>
> It will be good to see someone test with Eclipse and maybe remote 
> debugging interface someday.
>
>>   Right now, I am just at the point where I’m starting to compare 
>> inputs with outputs (well, a little beyond it).  I would rather 
>> continue with what I have, believing that programmers will write 
>> code that will be easily debugged, than write some functional stuff 
>> that requires a Lisp PhD to debug—or clicking down a whole 
>> hierarchy of objects.  Yes, I understand that functional 
>> programming is the hot thing to do now.  I don’t think people 
>> should get PhDs in order to debug my code.
>
> i think LISP stands for Lots of Idiotic Stupid Parentheses, not a 
> Ph.D. requirement.  8)
>
>> Yes, I realize some environments make it extremely easy to debug 
>> large functional objects.  Can we document which ones?
>>>
>>> The more difficult your program is to write, the more difficult is 
>>> it to debug.
>>>
>>> “Debugging is twice as hard as programming”
>
> Yup. and Netbeans works for me.
>
> Frankly with the declarative style, as i'm getting used to it, I 
> needed debugging less because declarative provides javadoc prompts 
> as you write that explain your options as you need to know them. 
> Thus easier to avoid mistakes that require later debugging.
>
>>> D3.js follows along with the functional methodology and I like it. 
>>> It also allows you to define variables (read DEF and USE).
>
> I'm looking forward to revisiting that.  The Java declarative 
> approach looks quite similar.
>
> The more we all do, the more likely it is that common programming 
> patterns will emerge.
>
>>> When I was originally converting XML to Java, I chose Object 
>>> arrays.  Not a type safe approach.
>
> X3DJSAIL to the rescue, everything is strongly typed.   (Thank you 
> X3D Schema and X3D Object Model!)
>
>>> Also any Java code in a single chunk is going to run into the 
>>> method size constraint.
>
> hmmm interesting, haven't hit that yet, found more information at
>
> http://stackoverflow.com/questions/17422480/maximum-size-of-a-method-in-java-7-and-8
>
>>  We should pick the best method which allows us to break the code 
>> up into separate methods (and how will we name those methods?).
>
> You can break up declarative blocks anywhere you want.  2 or more 
> pieces get saved as individual objects and stitched back together by 
> their parent object.
>
> btw it wouldn't surprise me if Java 8 figured out how to handle that 
> automatically... it is theoretically possible. testing will tell.
>
> With each release I fix other small problems and optimize further as 
> appropriate, and so it is probably good to run your generator again. 
> Hopefully your build's error list is gradually shrinking, just as it 
> did during our JSON development.
>
> Repeating: very grateful for the insightful analysis!  Thank you 
> 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 




More information about the x3d-public mailing list