[x3d-public] [x3d] V4.0 Open discussion/workshopon X3DHTML integration

[doug sanden]

3-step 'Creative Strategy'
http://cup.columbia.edu/book/creative-strategy/9780231160520
https://sites.google.com/site/airdrieinnovationinstitute/creative-strategy
1. break it down (into problem elements)
2. search (other domains for element solutions)
3. recombine (element solutions into total solution)

e - problem element
d - domain offering solution(s) to problem elements
e-d matrix
______d1________d2______d3__________d4
e1
e2
e3
e4

Applied to what I think is the overall problem: 'which v4 technologies/specifications' or 'gaining consensus on v4 before siggraph'.
I don't know if that's the only problem or _the_ problem, so this will be more of an exercise to see if Creative Strategy works in the real world, by using what I can piece together from what your're saying as an example. 
Then I'll leave it to you guys to go through the 3 steps for whatever the true problems are.
Problem: v4 specification finalization
Step1 break it down:
e1 continuity/stability in changing/shifting and multiplying target technologies
e2 html integration > protos
e3 html integration > proto scripts
e4 html integration > inline vs Dom
e5 html integration > node/component simplification
e6 html integration > route/event/timer
e7 html integration > feature simplification ie SAI 
e8 siggraph promotion opportunity, among/against competing 3D formats / tools

Step 2 search other domains
d1 compiler domain > take a high-level cross platform language and compile it for target CPU ARM, x86, x64 
d2 wrangling: opengl extension wrangler domain > add extensions to 15 year old opengl32.dll to make it modern opengl
d3 polyfill: web browser technologies > polyfill - program against an assumed modern browser, and use polyfill.js to discover current browser capaiblities and fill in any gaps by emulating
d4 unrolling: mangled-name copies pasted into same scope - don't know what domain its from, but what John is doing when proto-expanding, its like what freewrl did for 10 years for protos
d5 adware / iframe / webcomponents > separate scopes 
-   https://blogs.windows.com/msedgedev/2015/07/14/bringing-componentization-to-the-web-an-overview-of-web-components/
 -  http://www.benfarrell.com/2015/10/26/es6-web-components-part-1-a-man-without-a-framework/
 -  React, dojo, polymer, angular, es6, webcomponents.js polyfill, shadoow dom,import, same-origin iframe

d6 server > when a client wants something, and says what its capabilities are, then serve them what they are capable of displaying
d7 viral videos

(its hard to do a table in turtle graphics, so I'll do e/d lists)
e1 / d1 compiler: have one high level format which is technology agnostic, with LTS long term stablility, and compile/translate to all other formats which are more technology dependent. Need to show/prove the high level can be transformed/ is transformable to all desired targets like html Dom variants, html Inline variants, and desktop variants
e4 / d1 including compiling to inline or dom variants
e1 / d6 server-time transformation or selection: gets client capabilities in request, and either 
-    a) transforms a generic format to target capabilities variant or
-    b) selects from among prepared variants to match target capaibilties, 
e5 / d1 compiler: can compile static geometry from high level nurbs/extrusions to indexedfaceset depending on target capabilities, need to have a STATIC keyword in case extrusion is animated?
e6 / d1 compiler transforms routes, timers, events to target platform equivalents

e5 / d2 extension wrangling > depending on capaiblities of target, during transform stage, substitute Protos for high level nodes, when target browser can't support the component/level directly
e5 / d3 polyfill > when a target doesn't support some feature, polyfill so it runs enough to support a stable format

e8 / d7 create viral video of web3d consortium deciding/trying-to-decide something. Maybe creative strategy step 3: decide among matrix elements at a session at siggraph with audience watching or participating in special "help us decide" siggraph session.

e2 / d5 webcomponents and proto scripts: create scripts with/in different webcomponent scope; 
e3 / d5 webcomponents make Scene and ProtoInstance both in a webcomponent, with hierarchy of webcomponents for nested protoInstances.
e2+e3 / d4 unrolling + protos > unroll protos and scripts a) upstream/on server or transformer b) in client on demand
 
e7 / d6 server simplifies featuers ie SAI or not based on client capabilities
e7 / d1 compiler compiles out features not supported by target client

____d1___d2___d3___d4___d5___d6___d7
e1 __ * _______________________  *
e2   _________________ *___*
e3   _________________ *___*
e4  _*                   
e5  _*_____*____*
e6  _*
e7  _*_________________________*
e8  ________________________________*

Or something like that, 
But would Step 3 creatively recombine element solutions into total solution still result in deadlock? Or can that deadlock be one of the problem elements, and domain solutions applied? For example does the compiler/transformer workflow idea automatically solve current deadlock, or does deadlock need more specific attention ie breakdown into elements of deadlock, searching domains for solutions to deadlock elements etc.

HTH
-Doug