[x3d-public] [x3d] Spec Comment by walroy on 19775-1: Abstract X3D Definitions - V3.3 [Mantis 1172] allowing optional support in component levels

Sat Sep 9 11:36:47 PDT 2017

Definitely an interesting topic!  Here are some responses regarding how we got here.

1. Implementation motivations.  I believe that the primary motivation for allowing "optional" support in lower levels is to provide flexibility for X3D players.  If a particular X3D player implements full functionality at a higher level, then it is not required to "dumb down" reduced support at lower levels in order to be compliant.

Encouraging complete capabilities without requiring further implementation effort or complexity is helpful to implementers, and also avoids potential insertion of unintended/unnecessary programming errors.

2. Authoring motivations.  A secondary benefit of listing "optional" support is that scene authors are made aware that, depending on which X3D player an end user employs to view the scene, such higher-level component capabilities may be present.  This helps the author ensure that their content is workable either way, which is important since they don't necessarily know what player gets used (and indeed each player's support is hopefully improving over time).  Of course if an author has strict content requirements and decides they don't want the possibility of higher-level support, they can simply avoid it (by completely removing FillProperties, for example).

Of course tasking an author to make multiple versions of a model for strictly meeting different levels of component support also adds complexity, versionitis problems, and potential unintended/unnecessary modeling errors.

3. Specification design principles.  In each case where optional support is listed in the specification, we have tried to ensure that no hard contradictions are inadvertently introduced, keeping author concerns foremost (since they are in best position to judge satisfactory content results).  These levels of support are also informed by respective relative goals of the X3D profiles (Interchange, Interactive, CADInterchange, Immersive, etc.).

Thus this approach allows adaptability for component extensibility, rather than strictly circumscribed capabilities at each level (which adds complexity and difficulty, for both player implementers and scene authors).

One might even consider this "optional support" approach for lower component levels to be an adaptation of:

==============================================================
Robustness principle (Postel's Law)
https://en.wikipedia.org/wiki/Robustness_principle

In computing, the robustness principle is a general design guideline for software:

     Be conservative in what you do, be liberal in what you accept from others (often reworded as "Be conservative in what you send, be liberal in what you accept").

The principle is also known as Postel's law, after internet pioneer Jon Postel, who wrote in an early specification of the Transmission Control Protocol that:[1]

     TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.
==============================================================

Looking forward to comparing these design considerations with your check cases to see if further improvements can be achieved.  Thanks Roy.

On 9/8/2017 7:22 AM, Roy Walmsley wrote:
> Hi,
> 
> For the specification comment detailed below I have raised Mantis issue
> 1172. This is accessible to Web3D members at
> http://www.web3d.org/member-only/mantis/view.php?id=1172.
> 
> All the best,
> 
> Roy
> 
> -----Original Message-----
> From: x3d [mailto:x3d-bounces at web3d.org] On Behalf Of Spec Feedback
> Sent: 08 September 2017 12:20
> To: x3d at web3d.org
> Subject: [x3d] Spec Comment by walroy on 19775-1: Abstract X3D Definitions -
> V3.3
> 
> -- Submitter indicates that this comment may be public: *Yes* --
> 
> Comment on 19775-1: Abstract X3D Definitions - V3.3 General - Exemplar: 7.5
> Support levels
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components
> /core.html#SupportLevels
> 
> -----------------
> Hypothesis: Optional feature within a level is pointless, and should be
> removed.
> 
> The value of optional support for features within X3D will principally be
> examined by conducting a review of an example. We will concentrate on the
> first component, i.e. the Core component and Core profile.
> Reference:
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components
> /core.html
> Reference:
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/coreprofil
> e.html
> 
> We will start with Table 7.2 - Core component support levels.
> Reference:
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components
> /core.html#t-Coresupportlevels
> 
> Reviewing the table look particularly at the last row under level 1. This
> lists the "Prototyping" feature as being "Optionally supported". What does
> that mean? This is explained in clause 4.5.3 Base components.
> Reference:
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.h
> tml#Basecomponents
> 
> In particular, look at the sixth paragraph, second sentence. It reads:
> "When it is indicated that a field is "optionally supported", an X3D browser
> is not required to support that field."
> 
> With that background in mind, let's look at a specific example. Consider
> that an author creates a scene where the content consists only of metadata
> nodes and WorldInfo. What PROFILE/COMPONENT statements should be made? This
> question is answered in principle in clause 7.2.5.3 PROFILE statement.
> Reference:
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components
> /core.html#PROFILEStatement
> 
> The opening paragraph of this clause reads as follows:
> "Every X3D application shall declare a profile at the beginning of
> execution.
> This declaration tells the browser the exact set of components and their
> support levels that are required for the application to run, allowing for a
> browser to dynamically load the appropriate components if it so desires, and
> providing a mechanism for strict conformance should the browser choose to
> enforce it. If a browser supports the combination of declared profile and
> components (see 7.2.5.4 COMPONENT statement), it may proceed with presenting
> the world; otherwise, it shall fail."
> 
> So, the author has to review the support level requirements for profiles and
> components for the nodes and features used in the content. Since this
> example only has metadata nodes and WorldInfo, we can see from Table 7.2
> that full support for these nodes is provided by Core component support
> level 1.
> Furthermore, reviewing Table A.2 - Components and levels, we can see that
> the Core profile specifies that the browser supporting the Core profile
> shall support the Core component at level 1. The author can conclude,
> therefore, that a PROFILE statement in the file can be (using the style of
> the
> standard):
> PROFILE
> No additional COMPONENT statements are required.
> 
> A further question is whether the PROFILE/COMPONENT statements should be the
> minimum required to display the file. The text in clause 7.2.5.3 (quoted
> above) perhaps implies that this is the case, but does not explicitly say
> so.
> So it is not incorrect for the author to have a PROFILE statement that
> specifies a more extensive profile, such as Interchange, or Immersive. It
> simply means that if more extensive profiles are specified, and the browser
> does not support them, even though it supports the Core profile, it shall
> fail to display the file, even though it could actually do so.
> 
> Now let us assume that the scene author adds a Prototype into the scene,
> while still not introducing any additional node types. What should form
> should the PROFILE/COMPONENT statements take now? Following the same
> procedures we look at Table 7.2. For level 1 support prototyping is
> optional.
> If the author only specified the Core component level 1 support, this would
> not specify the full set of features required to display the file. So the
> author is required to specify the Core component at level 2 support.
> Specifying the minimum support features would the author could proceed as
> follows:
> PROFILE
> COMPONENT  <2>
> 
> The general principle we deduce is that optional support has no value for a
> scene author.
> 
> Now, let's turn to the browser developer. Sticking initially to the example
> of the Core component, a browser might initially be created that only
> support the Core profile, that is, the Core component at level 1. Fine. Now,
> the developer decides to add prototype support. In this instance, since
> Prototyping is the only difference between the two levels, the developer now
> knows that the browser supports the Core component at level 2.
> 
> Extending this to a more complex component, look at the Shape component, and
> Table 12.4 - Shape component support levels.
> Reference:
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components
> /shape.html#t-supportlevels
> Concentrate on the Appearance node. In level 1, textureTransform is
> optionally supported. lineProperties, fillProperties and shaders are not
> supported. What value is there to the browser developer to know that the
> textureTransform field is optionally supported?
> 
> A developer could have reached the point where the browser supports the
> Shape component at level 1. Thereafter, the developer might add additional
> support in a piecemeal fashion, say adding support for lineProperties. There
> is no statement saying this is "optionally supported". If the browser is
> presented with a scene that specified the Shape component at level 2, and
> yet that scene is only level 1 with the exception that it has lineProperties
> specified, the browser could display the file. Yet, according to the
> standard, it shall fail to load the file. Alternatively, the developer
> could, instead of lineProperties, have added support for textureTransform.
> Again, any scene author using that shall specify at least level 2 for the
> Shape component. The browser, however, does not support level 2, and shall,
> once again, fail to display the file.
> 
> So we conclude that optional support is of no value to the browser developer
> either.
> 
> Some questions:
> Do we want profile/component support to have "optional" capabilities? If so,
> since we require scene authors to specify at least the minimum
> profile/component support to be certain to display the file, they are of no
> value to either the scene author or the content developer. If we allow the
> scene author that uses "optional" capabilities to specify profile/component
> support at the lower level where that support is optional, then browsers
> will be unable to determine from the profile/component statement alone
> whether they can display the file.
> 
> Either way, there are problems for the standard. In my view, all optional
> support should be removed. Then both scene authors and browser developers
> have all content for a specific component support level clearly defined,
> removing all ambiguity.
> -----------------
> 
> Submitted on Friday, 2017,  September 8 - 12:20pm by walroy (walroy )
> IP: 82.31.58.84
> 
> See: http://www.web3d.org/node/1694/submission/1458
> 
> 
> _______________________________________________
> x3d mailing list
> x3d at web3d.org
> http://web3d.org/mailman/listinfo/x3d_web3d.org
> 
> 
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> 

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