[x3d-public] [x3d] Spec Comment by walroy on 19775-1: Abstract X3D Definitions - V3.3 [Mantis 1172]

[Roy Walmsley]

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