[x3d-public] Inlining, importing higher profiles

[Andreas Plesch]

The difficulty with allowing browser.importDocument and replaceWorld
to load a higher than current profile seems to be that lazy loading
often uses asynchronous fetching and loading of the required
additional libraries. x-ite is an example. And SAI importDocument is
synchronous, as well as loadURL and CreateX3DFromURL .

If we consider a async. version of these SAI methods, the favoured
approach in javascript now is to return promises (rather than
supplying callbacks).

I think x-ite could implement importDocumentAsync, loadURLAsync and
CreateX3DFromURLAsync browser methods. In fact, I adjusted x_ite_dom
to asynchronously load the additionally required component libraries
for new scenes. I suppose all methods which return a X3DScene could
use such async versions due to the potential of lazy loading.

x-ite needs the additional component libraries already for parsing
since they register x3d nodes with the browser. So the async. lazy
loading needs to happen at the loading stage even if the loaded x3d
scene or subscene is then not actually used in a new world.

Should x3d consider asynchronous SAI methods ?

-Andreas

On Tue, Mar 12, 2019 at 3:10 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
>
> Thanks, good to see the spec. is clear on how Inline is supposed to be
> treated. Although I am not sure what the point is if the browser
> actually could support the higher profile in the Inline. I think a
> warning would suffice to alert the author that the scene itself may
> need optimization and that the Inline required additional resources.
> Anyways, it is more important to have a clear definition.
>
> That leaves the SAI functions. The main argument against allowing
> importDocument and replaceWorld to work with a higher profile than the
> existing world would be consistency with Inline but that is really a
> different scenario.
>
> -Andreas
>
> On Tue, Mar 12, 2019 at 2:40 PM Leonard Daly <Leonard.Daly at realism.com> wrote:
> >
> > Andreas,
> >
> > It's in http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#X3DUrlObject
> >
> > 4th paragraph (edited):
> >
> > 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 url field requests capabilities greater than its parent, the following actions shall occur:
> >
> > an error shall be generated,
> > the URL shall be treated as not interpretable as specified in 9.3.2 X3DUrlObject, and
> > the next URL shall be loaded and checked in accordance with 9.2 Concepts.
> >
> > For more information on URLs, see 9.2.1 URLs.
> >
> >
> > 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.
> >
> >
> > Leonard Daly
> >
> >
> > 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: https://github.com/create3000/x_ite/issues/43
> >
> >
> >
> >
> >
> >
> > --
> > Leonard Daly
> > 3D Systems & Cloud Consultant
> > LA ACM SIGGRAPH Past Chair
> > President, Daly Realism - Creating the Future
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453



-- 
Andreas Plesch
Waltham, MA 02453