[x3d-public] X3D minutes16 July 2020: Inline refresh, https, description; X3DUrlObject

[Don Brutzman]

Thanks to this refactoring of fields into the X3DUrlObject abstract type, an interesting additional possibility arises.

Inline already contains the /load/ field, defined as follows.  Looks like this capability might be usefully available for any url.  This would give authors better control over url retrieval performance (defer large textures until needed) and also offers opportunity for greater security: only load url content following user permission, for example.

===========================================
9.4.2 Inline

Inline : X3DChildNode, X3DBoundedObject, X3DUrlObject {
   SFBool   [in out] bboxDisplay FALSE
   SFBool   [in,out] load        TRUE
   SFNode   [in,out] metadata    NULL     [X3DMetadataObject]
   MFString [in,out] url         []       [URI]
   SFBool   [in out] visible     TRUE
   SFVec3f  []       bboxCenter  0 0 0    (-∞,∞)
   SFVec3f  []       bboxSize    -1 -1 -1 [0,∞) or −1 −1 −1
}
[...]
If the load field is set to TRUE (the default field value), the X3D file specified by the url field is loaded immediately. If the load field is set to FALSE, no action is taken. It is possible to explicitly load the URL at a later time by sending a TRUE event to the load field (e.g., as the result of a ProximitySensor or other sensor firing an event). If a FALSE event is sent to the load field of a previously loaded Inline, the contents of the Inline will be unloaded from the scene graph.

An event sent to url can be used to change the scene that is inlined by the Inline node. If this value is set after the Inline is already loaded, its contents will be unloaded and the scene to which the new URL points will be loaded.
===========================================

Specification is simple to improve: copy load field and adapt prose to inherited X3DUrlObject.

As before, default value of load TRUE means no backwards-compatibility issues.

No value seen to Inline support caveat in component level 2: "All fields except load which is optionally supported." Load is quite easy to implement (simple boolean) and multi-level complexity is unneeded.

I believe these consolidated improvements for description, load, refresh and https increase the capabilities and consistency of handling all external content contained in an X3D4 model.  This is better for implementers (simpler object-oriented design), authors (more powerful capabilities) and users (consistent approach to url content).

Initial testing with X3DUOM works satisfactorily.  Initial prose changes in Networking component checked in.  Will review with Dick during next specification editors' meeting, will continue with specification additions other nodes beyond Anchor and Inline.

As ever, thanks for all review of these improvements.  The upcoming public release of X3D4 draft should be interesting to many people.


On 7/18/2020 4:25 PM, Don Brutzman wrote:
> On 7/17/2020 9:51 AM, Don Brutzman wrote:
>> [...]
>>
>> 6. Specification readiness review
>>
>> [6] Mantis Issues List
>>      https://www.web3d.org/member-only/mantis/view_all_bug_page.php
>> [...]
>> e. Mantis 1273 Inline https support
>> f. Mantis 1262 Inline refresh
>> [...]
>>
>> Accepted [...]
> 
> Several refinements on these mantis issues, request external review please.  Hopefully OK.
> 
> ----
> 
> a. https support: rather than Inline, this actually belongs in
> 
> [1] Mantis 1273: https level support requirements should match http level support
>      https://www.web3d.org/member-only/mantis/view.php?id=1273
> 
> ====================================
> 9.2.1 Networking component, URLs
> 
> A URL (Uniform Resource Locator), described in 2.[RFC1738], is a form of Universal Resource Identifier (URI) that specifies a file located on a particular server and accessed through a specified protocol (e.g., http). In this part of ISO/IEC 19775, the upper-case term URL refers to a Uniform Resource Locator, while the italicized lower-case version url refers to a field which may contain URLs or in-line encoded data.
> 
> Higher levels of this component extend the URL support of a browser to additional forms of URI, such as supporting URNs (Uniform Resource Name), which are another form of URI. A URN allows an abstract resolution mechanism to be invoked to locate a resource (see 2.[RFC2141]). This allows a resource to be located on the local machine or a platform dependent resource to be located using the URN along with platform-specific identifiers.
> 
> For levels that support URNs, the url field shall also support the Web3D Consortium URN Namespace (see 2.[RFC3541]) and also support the Universal Media Library that may be accessed using that namespace. A URN allows an abstract resolution mechanism to be invoked to locate a resource (see 2.[RFC2141]). This allows a resource to located on the local machine or a platform dependent resource to be located using the URN along with platform specific identifiers. A component extension can extend the URL support of a browser by supporting other URN naming schemes. More information on the url field may be found in 9.3.2 X3DUrlObject.
> 
> More general information on URLs is described in 2.[RFC1738].
> ====================================
> 
> Interesting this clause says only "e.g http" (example given).  Suggested change: "(e.g http or https)" and then, in clause 9.5 Support levels,
> 
> Current entries:
> 
> ================================================
> Level     Prerequisites     Nodes/Features     Support
> 
> 2     Core 1          Protocols     file: and http: protocols are required.
>          Grouping 1
> [...]
> 
> 4     Core 1            Level 3 supported nodes, Support as specified for Level 3.
>          Grouping 1     Protocols             https: protocol is required.
>                     Communication security     HTTP and HTTPS username/password is required.
> ================================================
> 
> So editorial resolution of this accepted comment will simply be to merge level 4 requirements with level 2, then remove level 4.
> 
> ----
> 
> b. Consolidation of refresh:
> 
> [2] Mantis 1262 : new field /refresh/ for Inline, ImageTexture etc.
>      https://www.web3d.org/member-only/mantis/view.php?id=1262
> 
> The following nodes are all affected by suggested changes:
> 
> [2] X3DJSAIL Package org.web3d.x3d.sai.Networking Interface X3DUrlObject
>      https://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/sai/Networking/X3DUrlObject.html
> 
>>  All Known Subinterfaces:
>>     Anchor, AudioClip, DISEntityTypeMapping, GeoMetadata, ImageCubeMapTexture,
>>     ImageTexture, ImageTexture3D, Inline, MovieTexture, PackagedShader, Script,
>>     ShaderPart, ShaderProgram, X3DScriptNode
> 
> Next, since each url field can refer to an external asset, it is appropriate to add a 'description' field.  We have node similarly in a number of other nodes (including Anchor already).
> 
> Next, rather than change each and every relevant node individually, am thinking the change is better applied to X3DUrlObject interface:
> 
> ====================================
> 9.3.2 X3DUrlObject
> 
> X3DUrlObject {
>    SFString [in,out] description    ""
>    MFString [in,out] url         [] [URI]
>    SFTime   [in,out] refresh     0  [0,+infinity)
> }
> ====================================
> 
> Suggested prose: "The /refresh/ field defines the interval in seconds that are necessary before an automatic reload of the current /url/ asset is performed. If the preceding file loading fails or the /load/ field is FALSE, no refresh is performed. If performed, a refresh attempts to reload the currently loaded entry of the url list. If a refresh fails to reload the currently loaded url entry, the browser retries the other entries in the /url/ list."
> 
> We should add:
> 
> "NOTE. Automatically reloading content can have security considerations and needs to be considered carefully."
> 
> Variations among nodes implementing X3DUrlObject can be handled cleanly in specification prose as follows:
> 
> 9.4.1 Anchor
> 
>      "The /refresh/ field has no effect."
> 
> 29.3.1 X3DScriptNode
> 
>      "If the /refresh/ field results in a new script getting loaded or the prior script getting reloaded,
>       then all fields are re-initialized to their initially defined values, and
>       the initialize() method is invoked, if provided, as defined in 29.2.3 initialize() and shutdown()."
> 
> Does this look OK?  Anything else to consider?
> 
> all the best, Don

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/brutzman