<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Andreas,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">It's in
<a class="moz-txt-link-freetext" href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#X3DUrlObject">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#X3DUrlObject</a></div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">4th paragraph (edited):</div>
<div class="moz-cite-prefix"><br>
</div>
<blockquote>
<div class="moz-cite-prefix">
<p>It shall be an error to specify a file in the URL field that
has a set of component definitions that is not a subset of the
components of the containing world. In addition, the
components shall not be of a higher support level than those
used by the containing world.... When the world indicated by
the
<em>url</em> field requests capabilities greater than its
parent, the following actions shall occur:</p>
<ul>
<li>an error shall be generated,</li>
<li>the URL shall be treated as not interpretable as specified
in <a
href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#X3DUrlObject">9.3.2
<i>X3DUrlObject</i></a>, and</li>
<li>the next URL shall be loaded and checked in accordance
with <a
href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#Concepts">9.2
Concepts</a>.</li>
</ul>
<p>For more information on URLs, see <a
href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#URLs">9.2.1
URLs</a>. <br>
</p>
<p><br>
</p>
</div>
</blockquote>
<div class="moz-cite-prefix">
<p>This was based on design decisions ~20 years ago. The WG
explicitly considered lazy loading and decided that the
optimizations available at the beginning of the file overrode
the feature of increasing support (profile or component) later
on. Nothing prevents a browser from lazing loading capabilities,
but it's suppose to limit that to what was originally declared.
<br>
</p>
<p><br>
</p>
<p>Leonard Daly<br>
</p>
</div>
<blockquote>
<div class="moz-cite-prefix"><br>
</div>
</blockquote>
<blockquote type="cite"
cite="mid:CAKdk67ui83qUY=5CDXii91M2JBxskUGTQfSG5wjb8CDU2Z48yQ@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">X-ITE is now loading support for some, less common components on
demand, eg. depending on profile and component statements in a scene.
This may lead to consequences on how external SAI and Inline are
treated which I want to clarify. I came across this since it affects
my dom bridge.
The question is if inlining or importing a Scene requiring a higher
profile (say Full) into a scene with a lower profile (say Interactive)
should be possible, eg. have the browser accept the higher profile
nodes.
The answer seems like the browser should just work with the higher
profile nodes, in both cases, Inline and
browser.replaceWorld(new_scene). But I could not find guidance in the
spec. and X-ITE currently does not do that since it only seems to load
needed components on loading of the initial scene.
The more common scenario is a higher profile Inline, which is using
say geospatial nodes, being inlined into a lower profile scene. I
think not specifying a profile for a scene just means the browser
should use its highest level of support since the point of profiles is
that a browser can warn or reject if it cannot support a scene. Is
that the main point ?
A question in this case is if SAI properties Scene.components or
Scene.profile should then report the elevated, higher level or the
original level.
Due to on-demand loading of additional libraries, there is some logic
for a browser to not support higher profiles in Inlines although it
could. Should there be a directive in the spec, to clarify that this
kind of elevating should be supported anyways, or should a decision be
left to the browser ?
For the dom bridge I use the importDocument and replaceWorld browser
services, for initial loading into a default empty Scene.
Since here the new scene completely replaces the old scene, there is
really no reason why a higher profile could not replace a lower
profile scene. But perhaps I am overlooking something since X-ITE does
not allow it ? Should this be explicitly allowed in the spec. ?
Here is a github issue: <a class="moz-txt-link-freetext" href="https://github.com/create3000/x_ite/issues/43">https://github.com/create3000/x_ite/issues/43</a>
</pre>
</blockquote>
<p><br>
</p>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Past Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>