<div dir="ltr">rubik*.x3d provide fairly good testing of nesting, but probably not perfect.   Have you tested the t1.x3d example yet?<div><br></div><div>Thanks,</div><div><br></div><div>John</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 5, 2020 at 2:24 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I added an example of a Prototype generating an output event, an<br>
IntegerTrigger which only triggers upon receiving true:<br>
<br>
<a href="https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html" rel="noreferrer" target="_blank">https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html</a><br>
<a href="https://5eda866f96703e0007fba0af--x3dom.netlify.app/examples/functional/proto/inline.html" rel="noreferrer" target="_blank">https://5eda866f96703e0007fba0af--x3dom.netlify.app/examples/functional/proto/inline.html</a><br>
<br>
The implementation adds forwarding of internal node generated events<br>
to the ProtoInstance pseudo node, using the internal x3dom route<br>
mechanism.<br>
<br>
 I think that concludes this effort for Prototype support in x3dom.<br>
Most functionality should be available.<br>
<br>
Missing features are<br>
<br>
- DOM based modification of ProtoInstance field values (probably possible)<br>
- routing of node value fields (in x3dom in general), but it is<br>
possible to use ProtoInstance fieldValue for node values.<br>
- no Script node support (in x3dom in general), unrelated although<br>
Scripts are very often used in Prototypes.<br>
<br>
There are no plans from my side to add support for these missing features.<br>
<br>
Builds for testing more thoroughly are available here:<br>
<br>
<a href="https://5eda866f96703e0007fba0af--x3dom.netlify.app/" rel="noreferrer" target="_blank">https://5eda866f96703e0007fba0af--x3dom.netlify.app/</a><br>
<br>
In particular, nested situations need testing, eg. ProtoInstances in<br>
ProtoDeclaration, ProtoInstances in ProtoInstance fields, and<br>
ProtoDeclarations in ProtoInstances (if that makes sense).<br>
<br>
I should check the castle library of examples.<br>
<br>
After a period of testing, ExternProto support should be relatively<br>
less complicated to provide.<br>
<br>
Looking forward to any reports,<br>
<br>
-Andreas<br>
<br>
On Thu, Jun 4, 2020 at 1:56 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
><br>
> Just another incremental update which enables event routing into<br>
> ProtoInstances, via forwarding to the internal nodes:<br>
><br>
> <a href="https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html" rel="noreferrer" target="_blank">https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html</a><br>
> <a href="https://5ed930d641a27700082647b9--x3dom.netlify.app/examples/functional/proto/inline.html" rel="noreferrer" target="_blank">https://5ed930d641a27700082647b9--x3dom.netlify.app/examples/functional/proto/inline.html</a><br>
><br>
> Sofar it was possible to treat ProtoInstance as a statement without<br>
> generating a full X3DNode derived member of the scene graph. This was<br>
> easier to reason about, following the expansion approach. But I start<br>
> to think it required essentially reimplementing enough of the X3DNode<br>
> related functionality that it may be time to try to switch to have a<br>
> ProtoInstanceNode itself in the scenegraph which then internally<br>
> represents itself with the Proto definition.<br>
><br>
> What would be a good example to test routing events emitted from a<br>
> ProtoInstance, without a script node ? Eg. a useful Proto which<br>
> generates events ? Perhaps a combination of event utilities ?<br>
><br>
> -Andreas<br>
><br>
> On Wed, Jun 3, 2020 at 7:17 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
> ><br>
> > I could enable custom fields for Protos, eg. ProtoInterface,<br>
> > IS/connect and ProtoInstance fieldValue, to a usable degree:<br>
> ><br>
> > <a href="https://5ed82885ae201410e81024b3--x3dom.netlify.app/examples/functional/proto/inline.html" rel="noreferrer" target="_blank">https://5ed82885ae201410e81024b3--x3dom.netlify.app/examples/functional/proto/inline.html</a><br>
> > <a href="https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html" rel="noreferrer" target="_blank">https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html</a><br>
> ><br>
> > ( key 'a' or 'r' of you do not see the fish, to adjust the view. )<br>
> ><br>
> > SFNode type fields work, MFNode type fields perhaps also. Initial<br>
> > value from ProtoInterface, and using the ProtoInstance field value<br>
> > otherwise should work. Routing from and to a ProtoInstance does not<br>
> > work yet. Is there an example _without_ Script node which uses routes<br>
> > from or to a ProtoInstance ?<br>
> ><br>
> > I also came across the question what to do if in a ProtoBody a node<br>
> > which has a IS field connection to a ProtoField with an initial value,<br>
> > also has a field value for the same field. Here is an example:<br>
> ><br>
> > <ProtoInterface><br>
> >   <field accessType='inputOutput' name='color' type='SFColor' value='0,0,0'/><br>
> > ...<br>
> ><br>
> > <ProtoBody><br>
> >   <Material diffuseColor='1,0,0'><br>
> >      <IS><br>
> >         <connect protoField='color' nodeField='diffuseColor' /><br>
> > ...<br>
> ><br>
> > Is the initial color 0,0,0 (black) or 1,0,0 (red) ? Probably black.<br>
> ><br>
> > To avoid this redundancy, the initial value could only be defined in<br>
> > the ProtoBody, in a future iteration of X3D.<br>
> ><br>
> > All the code is still NodeNameSpace.js. It was possible to keep it<br>
> > separate from existing functions. The approach for field manipulation<br>
> > is largely via DOM updates of cloned ProtoBodies. This avoids having<br>
> > to deal with field value types.<br>
> ><br>
> > I have an idea for Routing, so this is next. A good example would be<br>
> > great. Perhaps animating the table colors is an easy one first.<br>
> ><br>
> > -Andreas<br>
> ><br>
> > On Mon, Jun 1, 2020 at 8:09 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
> > ><br>
> > > Ok, true.<br>
> > ><br>
> > > If default values are the main reason to have a ProtoInterface, they could be just moved into the connect tag as a value attribute.<br>
> > ><br>
> > > Alternatively, the spec. could define that default values always fall back to the default value of the connected field of a native x3d node. The recommendation is any case to provide values for all fields in a ProtoInstance since a Proto may not be well documented.<br>
> > ><br>
> > > So simplifying protos may be possible by only relying on IS connections to define fields and omitting or moving the ability to allow custom default values.<br>
> > ><br>
> > > ProtoInterface does provide a nice, consolidated place to list all parameters for a Proto. But that is really a documentation feature, and ProtoDeclares typically are accompanied by an example ProtoInstance intended to show how to use Proto parameters/fields.<br>
> > ><br>
> > > Lastly, ProtoInterface does allow restricting access to native inputoutput fields to only input or only output. But when is that ability really useful ? Authors know how a Proto is intended to be used, and implementations have to support all access types in any case.<br>
> > ><br>
> > > Protos are very verbose in the xml encoding. So not needing a ProtoInterface section would help a little with cutting down this verbosity.<br>
> > ><br>
> > > Andreas<br>
> > ><br>
> > > ---on the phone---<br>
> > ><br>
> > > On Sun, May 31, 2020, 7:11 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
> > >><br>
> > >> We need protointerface for default values.<br>
> > >><br>
> > >> On Sun, May 31, 2020 at 4:50 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
> > >>><br>
> > >>> I adopted the idea to put the helper/sibling nodes of a ProtoInstance<br>
> > >>> into a Switch node, which is added as a root node to the main scene.<br>
> > >>> See the new MaterialBlinker proto here:<br>
> > >>><br>
> > >>> <a href="https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html" rel="noreferrer" target="_blank">https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html</a><br>
> > >>> <a href="https://5ed41e4b7244550007f7272f--x3dom.netlify.app/examples/functional/proto/inline.html" rel="noreferrer" target="_blank">https://5ed41e4b7244550007f7272f--x3dom.netlify.app/examples/functional/proto/inline.html</a><br>
> > >>><br>
> > >>> <a href="https://github.com/andreasplesch/x3dom/blob/gh-pages/test/functional/proto/MaterialBlinker.x3d" rel="noreferrer" target="_blank">https://github.com/andreasplesch/x3dom/blob/gh-pages/test/functional/proto/MaterialBlinker.x3d</a><br>
> > >>><br>
> > >>> The added switch node exists only in the x3d graph, not in the dom<br>
> > >>> graph, so is kind of hidden.<br>
> > >>><br>
> > >>> This is starting to have wider use compared to DEF/USE instancing.<br>
> > >>><br>
> > >>> The next step would be routable fields. It would be nice to break down<br>
> > >>> that functionality into smaller units.<br>
> > >>><br>
> > >>> One way to think about IS/connect is to ignore the ProtoInterface<br>
> > >>> definition initially and use directly the field names mentioned in the<br>
> > >>> connect tag to establish additional internal routes. It may be<br>
> > >>> preferable to modify routes since sofar there is no actual<br>
> > >>> ProtoInstanceNode node with actual fields. An idea may be to define<br>
> > >>> such a node which does not do anything other than define the custom<br>
> > >>> fields and forward events to the internal nodes.<br>
> > >>><br>
> > >>> Would it be possible to autogenerate a ProtoInterface definition from<br>
> > >>> a ProtoBody with IS connections ? The fields names are all there and<br>
> > >>> the access types just follow the types from the native nodes. Do we<br>
> > >>> actually need a ProtoInterface definition ?<br>
> > >>><br>
> > >>> -Andreas<br>
> > >>><br>
> > >>> On Sat, May 30, 2020 at 12:30 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
> > >>> ><br>
> > >>> > Sorry, I misunderstood how Switch could help. I missed the expanded example:<br>
> > >>> ><br>
> > >>> > <a href="http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/MaterialModulatorPrototypeExpandedIndex.html" rel="noreferrer" target="_blank">http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/MaterialModulatorPrototypeExpandedIndex.html</a><br>
> > >>> ><br>
> > >>> > The Switch node containing the sibling/helper nodes is just appended<br>
> > >>> > to the end of the main scene, not after the main node. Does that work<br>
> > >>> > in general ? It may (but nesting?). It also means that the siblings<br>
> > >>> > nodes can only be X3DChildNodes which also may be ok. Could there be<br>
> > >>> > non child nodes which are used as helpers nodes ? I cannot think of<br>
> > >>> > any right now although the spec. does not seem to restrict what is<br>
> > >>> > inside a Proto definition.<br>
> > >>> ><br>
> > >>> > Let's think about nesting and DEF/USE. USE of ProtoInstance may work<br>
> > >>> > by just placing a USE instance of the main node, upon expansion or<br>
> > >>> > scene construction. I think it could.<br>
> > >>> ><br>
> > >>> > But where would the sibling Switch go for a nested ProtoInstance,<br>
> > >>> > inside a ProtoBody ?<br>
> > >>> ><br>
> > >>> > I will try to add some diagrams but this will be quite dizzying.<br>
> > >>> > Apologies for that.<br>
> > >>> ><br>
> > >>> > If the ProtoInstance is or is inside the first, main node, upon<br>
> > >>> > expansion a potential sibling Switch would be appended after the<br>
> > >>> > siblings of the first node, as another sibling:<br>
> > >>> ><br>
> > >>> > ProtoBody<br>
> > >>> >   main node: ProtoInstance<br>
> > >>> >   siblings<br>
> > >>> ><br>
> > >>> > expansion -><br>
> > >>> ><br>
> > >>> > ProtoBody<br>
> > >>> >   main node: ProtoInstanceExpandedMain<br>
> > >>> >   siblings<br>
> > >>> >   ProtoInstanceExpandedSwitch<br>
> > >>> ><br>
> > >>> > Then, the expansion of the ProtoBody would place a Switch node<br>
> > >>> > containing all siblings which now includes the inner sibling Switch at<br>
> > >>> > the end of the main scene. That sounds right to me.<br>
> > >>> ><br>
> > >>> > If the ProtoInstance is a sibling the first, main node, upon expansion<br>
> > >>> > a potential sibling Switch would be appended after the siblings of the<br>
> > >>> > first node, as another sibling, along with the main node:<br>
> > >>> ><br>
> > >>> > ProtoBody<br>
> > >>> >   main node<br>
> > >>> >   siblings<br>
> > >>> >   ProtoInstance<br>
> > >>> ><br>
> > >>> > expansion -><br>
> > >>> ><br>
> > >>> > ProtoBody<br>
> > >>> >   main node<br>
> > >>> >   siblings<br>
> > >>> >   ProtoInstanceExpandedMain<br>
> > >>> >   ProtoInstanceExpandedSwitch<br>
> > >>> ><br>
> > >>> > Then, the expansion of the ProtoBody would place a Switch node<br>
> > >>> > containing all siblings which now includes both the inner main and the<br>
> > >>> > inner sibling Switch at the end of the main scene. That looks also<br>
> > >>> > reasonable at first glance.<br>
> > >>> ><br>
> > >>> > In that sense ProtoInstance would require ProtoDeclare or ProtoBody to<br>
> > >>> > be recognized similar to Scene, for expansion purposes. That is<br>
> > >>> > similar to how x-ite works. For x-ite a ProtoDeclaration is a<br>
> > >>> > ExecutionContext.<br>
> > >>> ><br>
> > >>> > Well, I think this helped me understand Protos a bit better in any case,<br>
> > >>> ><br>
> > >>> > -Andreas<br>
> > >>> ><br>
> > >>> > On Fri, May 29, 2020 at 7:36 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
> > >>> > ><br>
> > >>> > > Don suggested a Switch node at one point (thanks Don).<br>
> > >>> > ><br>
> > >>> > > On Fri, May 29, 2020 at 1:28 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
> > >>> > >><br>
> > >>> > >> Internal namescopes and better parsing made nested ProtoDeclares<br>
> > >>> > >> inside ProtoBody and internal ROUTEs work:<br>
> > >>> > >><br>
> > >>> > >> <a href="https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html" rel="noreferrer" target="_blank">https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html</a><br>
> > >>> > >> <a href="https://5ed144877a8ae8000756ddd1--x3dom.netlify.app/examples/functional/proto/inline.html" rel="noreferrer" target="_blank">https://5ed144877a8ae8000756ddd1--x3dom.netlify.app/examples/functional/proto/inline.html</a><br>
> > >>> > >><br>
> > >>> > >> I am still not sure how to think about multiple nodes in a ProtoBody<br>
> > >>> > >> template since these are not scenes. Many examples seem to have only<br>
> > >>> > >> one node, and only routes outside of it.<br>
> > >>> > >><br>
> > >>> > >> Conceptually, it is pretty clear that the first node is THE node, and<br>
> > >>> > >> other nodes do not render but are active and can be connected.<br>
> > >>> > >><br>
> > >>> > >> Let's look at the Material Modulator example:<br>
> > >>> > >> <a href="http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/MaterialModulatorIndex.html" rel="noreferrer" target="_blank">http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/MaterialModulatorIndex.html</a><br>
> > >>> > >><br>
> > >>> > >> The main node is the Material node but then there are Script and<br>
> > >>> > >> TimeSensor siblings, and routes.<br>
> > >>> > >><br>
> > >>> > >> So the instance will be of Material node kind, an<br>
> > >>> > >> X3DAppearanceChildNode. This allows the instance to be accepted as a<br>
> > >>> > >> value of the Material field in an Appearance node.<br>
> > >>> > >><br>
> > >>> > >> But the Script and TimeSensor sibling instances will not be able to<br>
> > >>> > >> continue to live as siblings next to the instanced Material node since<br>
> > >>> > >> they are not X3DAppearanceChildNodes. They will need to live somewhere<br>
> > >>> > >> else but still be able to control the instanced Material node.<br>
> > >>> > >><br>
> > >>> > >> So a straight transfer of a one to one instance to the scene seems out<br>
> > >>> > >> of the question.<br>
> > >>> > >><br>
> > >>> > >> I kind of hope I am missing something ? Is there another way to think<br>
> > >>> > >> about Protoinstances ?<br>
> > >>> > >><br>
> > >>> > >> Probably time to look at other code for inspiration.<br>
> > >>> > >><br>
> > >>> > >> -Andreas<br>
> > >>> > >><br>
> > >>> > >> On Fri, May 29, 2020 at 8:39 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
> > >>> > >> ><br>
> > >>> > >> > I added a few more Proto test examples to<br>
> > >>> > >> ><br>
> > >>> > >> > <a href="https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html" rel="noreferrer" target="_blank">https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html</a><br>
> > >>> > >> ><br>
> > >>> > >> > and<br>
> > >>> > >> ><br>
> > >>> > >> > <a href="https://5ed100c873166e0006438ab0--x3dom.netlify.app/examples/functional/proto/inline.html" rel="noreferrer" target="_blank">https://5ed100c873166e0006438ab0--x3dom.netlify.app/examples/functional/proto/inline.html</a><br>
> > >>> > >> ><br>
> > >>> > >> > That includes a NIST example which uses internal routing and one which<br>
> > >>> > >> > has ProtoDeclare inside ProtoBody, nested five deep. These are good<br>
> > >>> > >> > targets to get to work before thinking about fields and interface.<br>
> > >>> > >> ><br>
> > >>> > >> > <a href="https://www.web3d.org/x3d/content/examples/ConformanceNist/Miscellaneous/PROTO/index.html" rel="noreferrer" target="_blank">https://www.web3d.org/x3d/content/examples/ConformanceNist/Miscellaneous/PROTO/index.html</a><br>
> > >>> > >> ><br>
> > >>> > >> > -Andreas<br>
> > >>> > >> ><br>
> > >>> > >> > On Thu, May 28, 2020 at 8:35 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
> > >>> > >> > ><br>
> > >>> > >> > > It turns out that github pages does not like serving all the little js<br>
> > >>> > >> > > files making up x3dom separately.<br>
> > >>> > >> > ><br>
> > >>> > >> > > Here is a complete build with the example:<br>
> > >>> > >> > ><br>
> > >>> > >> > > <a href="https://5ed055bd4da4fa0007bf3d0a--x3dom.netlify.app/examples/functional/proto/inline.html" rel="noreferrer" target="_blank">https://5ed055bd4da4fa0007bf3d0a--x3dom.netlify.app/examples/functional/proto/inline.html</a><br>
> > >>> > >> > ><br>
> > >>> > >> > > -Andreas<br>
> > >>> > >> > ><br>
> > >>> > >> > ><br>
> > >>> > >> > ><br>
> > >>> > >> > > On Thu, May 28, 2020 at 6:43 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
> > >>> > >> > > ><br>
> > >>> > >> > > > I could not resist a proof of concept for the subgraph inclusion part of Protos.<br>
> > >>> > >> > > ><br>
> > >>> > >> > > > <a href="https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html" rel="noreferrer" target="_blank">https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html</a><br>
> > >>> > >> > > ><br>
> > >>> > >> > > > This is an absolutely minimal start. There is only creation of<br>
> > >>> > >> > > > instances, using only the first element in the ProtoBody. There is no<br>
> > >>> > >> > > > ProtoInterface or events handling.<br>
> > >>> > >> > > > It should work for all single node Protos.<br>
> > >>> > >> > > ><br>
> > >>> > >> > > > But it only took a few lines in the right place<br>
> > >>> > >> > > > (<a href="https://github.com/andreasplesch/x3dom/commit/1e0ff82c2f7c77adcb521d62ff5172cf159943fb" rel="noreferrer" target="_blank">https://github.com/andreasplesch/x3dom/commit/1e0ff82c2f7c77adcb521d62ff5172cf159943fb</a>).<br>
> > >>> > >> > > ><br>
> > >>> > >> > > > I understand that only the first node in a ProtoBody is used for the<br>
> > >>> > >> > > > template. It can be of course a grouping node. Other nodes in the<br>
> > >>> > >> > > > ProtoBody can affect the first node with internal routing.<br>
> > >>> > >> > > ><br>
> > >>> > >> > > > Inline is in effect a grouping node but this will not translate to<br>
> > >>> > >> > > > ProtoInstance. I will have to look at more examples to understand<br>
> > >>> > >> > > > better how multiple nodes are inserted with a single ProtoInstance.<br>
> > >>> > >> > > ><br>
> > >>> > >> > > > -Andreas<br>
> > >>> > >> > > ><br>
> > >>> > >> > > ><br>
> > >>> > >> > > ><br>
> > >>> > >> > > > On Thu, May 28, 2020 at 3:09 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
> > >>> > >> > > > ><br>
> > >>> > >> > > > > Let me write down a few notes on ProtoDeclare/Instance.<br>
> > >>> > >> > > > ><br>
> > >>> > >> > > > > - The expander approach would be ok for x3dom as well but I am not<br>
> > >>> > >> > > > > sure if it is easier to implement.<br>
> > >>> > >> > > > > - These are Statements and would be handled separately from Nodes,<br>
> > >>> > >> > > > > similar to ROUTE, in x3dom in NodeNameSpace.js<br>
> > >>> > >> > > > > - in x3dom gltf inlines are handled by translation to a (by default<br>
> > >>> > >> > > > > non-accessible) sub DOM, which is then tree parsed and added as a<br>
> > >>> > >> > > > > subgraph in a child namespace to the main scene. Similar to<br>
> > >>> > >> > > > > ProtoInstance this involves some processing before attaching to the<br>
> > >>> > >> > > > > main scene. So I think it would be not too hard to do the same for<br>
> > >>> > >> > > > > ProtoInstance by looking up the corresponding ProtoBody in a registry.<br>
> > >>> > >> > > > > The registry is populated while parsing, looking for ProtoDeclare<br>
> > >>> > >> > > > > elements.<br>
> > >>> > >> > > > > - the main challenge is how to implement custom fields, and 'IS' ing.<br>
> > >>> > >> > > > > For routing to ProtoInstances there needs to be a crossing of the<br>
> > >>> > >> > > > > namescope boundary.<br>
> > >>> > >> > > > > - ProtoInstances are more like Nodes than Statements, since they need<br>
> > >>> > >> > > > > to be included in traversing the scene.<br>
> > >>> > >> > > > > - not sure if x3dom currently has a way to send events into namescoped<br>
> > >>> > >> > > > > subgraphs (via IS/connect), and capture events from those (via<br>
> > >>> > >> > > > > IS/connect).<br>
> > >>> > >> > > > > - perhaps it makes sense to have the ProtoInstance statement construct<br>
> > >>> > >> > > > > a ProtoInstanceNode node to insert in the scenegraph. The statement<br>
> > >>> > >> > > > > takes care of field definitions for the node, and the node takes care<br>
> > >>> > >> > > > > of ISing and events during travesal.<br>
> > >>> > >> > > > ><br>
> > >>> > >> > > > > -Andreas<br>
> > >>> > >> > > > ><br>
> > >>> > >> > > > ><br>
> > >>> > >> > > > ><br>
> > >>> > >> > > > ><br>
> > >>> > >> > > > ><br>
> > >>> > >> > > > > On Thu, May 28, 2020 at 12:52 AM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
> > >>> > >> > > > > ><br>
> > >>> > >> > > > > > so perhaps this is the reasoning Leonard had.:<br>
> > >>> > >> > > > > ><br>
> > >>> > >> > > > > > Developers and designers want the full power of the web.   If I restrict people to inlines, they can’t use standard tools to inspect the DOM, especially where it’s critical.<br>
> > >>> > >> > > > > ><br>
> > >>> > >> > > > > > 1.   Should X3D4 allow all X3D elements in the HTML page or perhaps just a few?<br>
> > >>> > >> > > > > ><br>
> > >>> > >> > > > > > 2.  Should X3D4 allow Protos on the main HTML page?  Or only in inlines?<br>
> > >>> > >> > > > > ><br>
> > >>> > >> > > > > > John<br>
> > >>> > >> > > > ><br>
> > >>> > >> > > > ><br>
> > >>> > >> > > > ><br>
> > >>> > >> > > > > --<br>
> > >>> > >> > > > > Andreas Plesch<br>
> > >>> > >> > > > > Waltham, MA 02453<br>
> > >>> > >> > > ><br>
> > >>> > >> > > ><br>
> > >>> > >> > > ><br>
> > >>> > >> > > > --<br>
> > >>> > >> > > > Andreas Plesch<br>
> > >>> > >> > > > Waltham, MA 02453<br>
> > >>> > >> > ><br>
> > >>> > >> > ><br>
> > >>> > >> > ><br>
> > >>> > >> > > --<br>
> > >>> > >> > > Andreas Plesch<br>
> > >>> > >> > > Waltham, MA 02453<br>
> > >>> > >> ><br>
> > >>> > >> ><br>
> > >>> > >> ><br>
> > >>> > >> > --<br>
> > >>> > >> > Andreas Plesch<br>
> > >>> > >> > Waltham, MA 02453<br>
> > >>> > >><br>
> > >>> > >><br>
> > >>> > >><br>
> > >>> > >> --<br>
> > >>> > >> Andreas Plesch<br>
> > >>> > >> Waltham, MA 02453<br>
> > >>> ><br>
> > >>> ><br>
> > >>> ><br>
> > >>> > --<br>
> > >>> > Andreas Plesch<br>
> > >>> > Waltham, MA 02453<br>
> > >>><br>
> > >>><br>
> > >>><br>
> > >>> --<br>
> > >>> Andreas Plesch<br>
> > >>> Waltham, MA 02453<br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Andreas Plesch<br>
> > Waltham, MA 02453<br>
><br>
><br>
><br>
> --<br>
> Andreas Plesch<br>
> Waltham, MA 02453<br>
<br>
<br>
<br>
--<br>
Andreas Plesch<br>
Waltham, MA 02453<br>
</blockquote></div>