[x3d-public] IMPORT/EXPORT Use [was: Statement permitted placements]

John Carlson yottzumm at gmail.com
Sat Jul 15 14:46:39 PDT 2017


May I suggest we work on example with Protos?
https://coderextreme.net/X3DJSONLD/src/main/html/flowers.xhtml Let's make
this example use a single encoding for both X3DOM and Cobweb, (minus
headers, or including both sets of headers) so we can suss out the
difficulties.

On Jul 15, 2017 4:51 PM, "Don Brutzman" <brutzman at nps.edu> wrote:

> On 7/14/2017 12:08 PM, Leonard Daly wrote:
>
>> Roy did a very detailed analysis of statement location.
>>
>
> Yes.
>
> Getting consistent expressions among all the encodings and language
> bindings will help us avoid problems.  Once again, Object Model for X3D
> (OM4X3D) shows relevance and can help describe statement location in an
> object-oriented manner for language bindings.
>
> I think that any discussion of IMPORT / EXPORT statements may be premature
>> until it is figured out how files and their nodes will be inlined in HTML.
>> There is a single namespace and namescope in HTML causing the following
>> issues when X3D is integrated with DOM:
>>
>
> Leonard, not understanding why there seems to be a namespace conundrum, it
> does not have to the case.
>
> There are scene demos already showing event routing using DOM, event
> routing using ROUTES, and a mix (for example ROUTEs in Cobweb-supported
> scenes).
>
> Keeping HTML attributes for id associated with DOM events, and separately
> keeping X3D attributes DEF/USE for ROUTE events, avoids name-collision
> problems.
>
> This approach has even further appeal because it can work satisfactorily
> in a single global DOM tree (which I think you assume) or a primary +
> shadow DOM approach which decouples ordinary page-refresh HTML from
> high-frame-rate interactive 3D graphics.
>
> Scoping of X3D DEF/USE visibility already occurs within a ProtoDeclare,
> and within one or more loaded Inline subgraphs (which already handles your
> case 4 below), so it is not a far step to similarly define such
> scoping/separation of namespace tables once in the DOM.  The DOM has no
> knowledge of DEF/USE, X3D ROUTEs have no knowledge of id attributes, and so
> coexistence can occur without collision.
>
> In that sense, since the specifications are currently distinct: X3D ROUTE
> assing events to an HTML5/DOM id (or conversely, HTML5/DOM events to an X3D
> DEF node) is not defined, and only becomes a problem if new specification
> definitions create such a problem.  We do not have to create such a
> conundrum.
>
> This has been brought up a number of times but still does not appear in
> your list of alternatives.  Please consider how it avoids the difficulties
> you describe.  Perhaps there is a better way to describe how this can work?
>
> Simple illustrative diagram attached with descriptive prose in following
> Web3D 2017 presentations.  We can further refine and improve this loosely
> coupled approach based on implementation experience using X3DOM/Cobweb in
> various HTML browsers.  The "rosetta stone" bouncing-ball example (showing
> HTML5+DOM+SVG+HTML events+X3D+X3D events+user interaction) is a good place
> to start.
>
>         X3D Version 4
>         http://www.web3d.org/x3d4
>
>         "Future of X3D" presentation and detailed notes from Web3D 2017
> Conference, Brisbane Australia, 7 June 2017
>         http://www.web3d.org/sites/default/files/page/X3D%20Version%
> 204/FutureOfX3D.pdf
>         http://www.web3d.org/sites/default/files/page/X3D%20Version%
> 204/FutureOfX3dWeb3d2017June7.pdf
>         http://www.web3d.org/sites/default/files/image/wg/X3D%20Vers
> ion%204/PresentationPanoramaFutureOfX3dPaulGrimm20170607_
> 135611.1600x492.jpg
>
> This loose coupling may be a variation on your approach (C) below? - not
> sure.  Reconciling Inline/IMPORT/EXPORT names is the same for for event
> passing to/from any node.  If IMPORT/EXPORT only refer to a DEF name within
> scoped X3D scene graphs, no collisions occur (as already shown in other X3D
> encodings).
>
> In any case we can't conflate HTML5/DOM event passing with X3D event
> passing.  They are different.  W3C controls those specifications, while we
> are aligning X3D specifications to coexist well.  W3C describes functional
> semantics for the HTML5/DOM/SVG/MathML part of the DOM tree, we will
> describe functional semantics for the X3D part of the DOM tree.
>
> Thanks for considering these valuable possibilities.
>
>
> 1) All nodes are available to all other nodes at all times
>> 2) IMPORT does not have any meaning
>> 3) EXPORT does not have any meaning
>> 4) Uncertain how to handle a file that gets Inlined more than once since
>> all DEF and ID from the Inline will be duplicated
>>
>> Possible solutions are:
>> A) Do not put the contents of any Inline into the DOM
>> B) Do not put the contents of any X3D file into the DOM
>> C) Modify the DEF & ID values on each Inline so they are unique
>>
>> (A) has the potential problem of completely hiding all of the interior
>> nodes and making it unavailable. In this case IMPORT and EXPORT can be
>> defined to make sense by providing access to those fields. Unfortunately
>> this breaks a different goal of full DOM integration.
>>
>> (B) This is like (1), but more extreme. It essentially makes X3D
>> plugin-like in that there is complete separation between DOM and X3D.
>>
>> There is a variant on (A)/(B) where only certain (developer controllable)
>> Inline contents are loaded into the DOM. This partially breaks the goal of
>> DOM integration and still leaves the problem of keeping DEF/ID values
>> unique (C)
>>
>> (C) This solution creates a virtual namescope in that the DEF/ID values
>> are modified so that they are unique within the parent DOM. This is
>> potentially tricky since these values can be programmatically assembled. It
>> might be possible to make all of the necessary modifications to the nodes
>> in the Inline file, but unsolvable (or close to it) to change other code in
>> either the parent or other Inline nodes that may cross-refer to those
>> values.
>>
>>
>> --
>> *Leonard Daly*
>> 3D Systems & Cloud Consultant
>> LA ACM SIGGRAPH Chair
>> President, Daly Realism - /Creating the Future/
>>
>>
>> _______________________________________________
>> 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/brutzma
> n
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170715/7baa7c9f/attachment.html>


More information about the x3d-public mailing list