<div dir="ltr">.<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Inline (and related - some not yet defined) nodes are really important.<br>
They allow a developer to build a scene in pieces (or multiple<br>
developers to work on a scene). I cannot foresee a situation where<br>
something like that does not exist.<br>
<br></blockquote><div><br></div><div>The web community has recognized this as well and came up with web components. If x3d becomes intergrated into a web page dom, "Inline", "Macro" and protos will have a lot of overlap with those. In particular, I think "Inline" is very similar to HTML Imports. It may be difficult to have traditional X3D compartmentalization along side web components but perhaps not impossible.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The details of how to access the internals may change depending on how<br>
the data is loaded (potentially the data format) and the kind of<br>
protection that might be needed. For example a model may represent a<br>
part that should not be modified (because of licensing, etc.). The X3D<br>
library may need to enforce (to an extent) that restriction by not<br>
exposing that model to the DOM and user modification. Note that I am not<br>
arguing for absolute protection or DRM mechanisms.<br>
<br></blockquote><div><br></div><div>Yes, I thought the main motivation for EXPORT may be to control what is exposed. But then again, the inline node has to be able to be downloaded and therefore will be subject to any manipulation locally, including outside of X3D, so this control would be mostly symbolic, as far as I can see. Is it more useful than limiting to have such a barrier ?<br><br></div>-Andreas<br></div></div></div>