[x3d-public] X3D4 finalization endgame: Field naming reconciliation decision

Tue Dec 8 17:30:26 PST 2020

On 11/28/2020 12:13 PM, Don Brutzman wrote:
> Summary: further description of tradeoffs and a request for determining consensus follows.

Status:
a. Thanks to everyone considering and responding to this request on selected field renaming.
b. All responses to the request for determining consensus indicated "they could live with it."
c. Andreas pointed out some issues with including GeoLOD - agreed, removed from list.
d. Last X3D Working Group meeting determined that 'synonym' alternative was not advisable.
e. Michalis sent private concurrence with permission to share.
f. His note, updated fields list and original call for consensus follows.

Given consensus that everyone "can live with it" either way, and given that the cost tradeoff is either one-time adaptation now or inconsistent irregularity for future users, the best choice for all concerned seems clear.

Decision: we shall tip the balance of implementation effort to best benefit the future.  Thus we will rename irregular legacy fields, resulting in more consistent naming for X3D4 with no change in existing functionality for the renamed fields.

Next steps: I will work to apply the changes below to X3D4 prose and validation tools so that Web3D members and implementers next receive the best possible (and best achievable) draft specification.  This will happen in a matter of days.

Objections can of course always be posted.  Meanwhile work on converters and diagnostics will proceed apace, and the primary pressure will be to succeed using the best design approach.  I believe the "issue" will gradually disappear as regularized X3D4 support becomes easy and (hopefully) commonplace.

Again thanks for all contributions, onward we go.  Have fun with X3D!  8)

==========================================================> On 12/5/2020 2:27 PM, Michalis Kamburelis wrote:
>>
>> Hi,
>>
>> I didn't participate in this thread, as I have no strong opinion about
>> either the renames, or about the "introduce the notion of synonyms" to
>> X3D spec.
>>
>> I agree with whoever said that adding a concept of synonyms to X3D
>> spec seems like too much complication. Even if it is easy to implement
>> for browsers (it is), it's still an additional complication to an
>> already complicated standard
>>
>> Internally in CGE/view3dscene we already have a mechanism for
>> "aliases", to account for some field renames between VRML 2.0 -> X3D.
>> So we have this implementation "burden" anyway. Still, I'm happy to
>> "carry this burden", I do it because I want to support both VRML 2.0
>> and X3D 3.x and X3D 4.x. Probably, not everyone needs that --- I
>> imagine that if someone writes X3D viewer from scratch in 2021, they
>> will probably just ignore the VRML 2.0 existence.
>>
>> The renames you propose (as I understand, they are listed on
>> https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#fieldNameChanges
>> ). From important things, we have there ComposedCubeMapTexture,
>> TextureBackground fields' rename, but it's not a big issue for me.
>> Whether it happens, or not happens -- "I can live with it" either way
>>
>> As you see, I don't really have an opinion here (at least, not
>> something that wasn't already said by someone else). So I can live
>> with any solution.
>>
>> Feel free to quote me and/or repost this to x3d-public.
>>
>> Regards,
>> Michalis

==========================================================

[Box score: 7 nodes need changed field names, 2 are already accomplished, 2 are off the list.  For the email archive, here is that current list.]

* X3D Scene Authoring Hints, Potential future changes for improved consistency of field names
   https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#fieldNameChanges

Ongoing work for X3D Version 4 and X3D Unified Object Model (X3DUOM) makes a number of candidate optimizations possible and (in most cases) desirable. Consistent X3D scene-graph architecture across multiple file encodings and programming-language bindings is important.

The following consistency changes to SFNode/MFNode field names in X3D4 might reduce the number of containerField variations by more than half. Further simplification benefits are foreseen for X3D4 implementations, X3D authors, and X3D Ontology field disambiguation.

     1. CADFace issue Mantis 1234 to change unnecessarily different containerField='shape' and rename as containerField='children' instead.
     2. DISEntityTypeMapping: enter Mantis issue to change unnecessarily different containerField='mapping' and rename as containerField='children' instead.
     3. CollidableShape: enter Mantis issue to change unnecessarily different field name containerField='shape' (which has different semantics than CADFace shape field) and rename as containerField='children' instead.
     4. ComposedCubeMapTexture: enter Mantis issue to make six sets of field names identical for contained textures, e.g. backTexture becomes back etc.
     5. TextureBackground: same.
     6. LoadSensor: enter Mantis issue to change unnecessarily different field name containerField='watchList' and rename as containerField='children' instead. Child node restrictions can achieve a functionally equivalent effect and improve the object-oriented design.
     7. ParticleSystem: enter Mantis issue to change unnecessarily different field names colorRamp, texCoordRamp and rename as regular defaults color, texCoord instead. Also allow TextureCoordinateGenerator as an alternative to TextureCoordinate for that child node.

Some related refinements do not require changes in field names.

     8. Collision: typed content-model definitions for contained nodes (containerField='children') are insufficiently strict. See issue Mantis 1149 which suggests node-type restrictions "matching CADFace shape field" instead. (Hence this change adds further consistency if applied.)
     9. GeoMetadata: has X3DUrlObject object interface applied for consistency, no changes in field names necessary.

Not accepted for X3D4 draft: nodes with working functionality but design refinements are not planned.

     * GeoLOD: see issue Mantis 920 to change unnecessarily different field name containerField='rootNode' and rename as containerField='children' instead. Also enter Mantis issue to implement object interface X3DUrlObject.
     * Nodes in the Programmable shader component all field names deserve a further close look. While everything works correctly, node naming is confusing and clarity is certainly improvable.

Few changes are needed for upgrading X3D and browsers from X3D3 to X3D4. These changes require modified parsers, validators and converters for proper handling. Performing this one-time effort now, when progressing from X3D3 to X3D4, means that future authors and modelers have a streamlined consistent interface and less legacy baggage from earlier evolutions of the language.

These proposed improvements emphasize ease of X3D4 authorability and animation in the future.

These suggested changes to field names (for a total of 7 remaining nodes) are receiving close scrutiny by Web3D Consortium members with corresponding technical review by the X3D Community. Companies, institutions, agencies and individuals are invited to Join Web3D Consortium to participate and influence this important continuing evolution of X3D.
==========================================================

Original call for consensus follows.  Again thanks to everyone helping with this group ascertainment.

>> On 11/28/2020 12:13 PM, Don Brutzman wrote:
>>> Summary: further description of tradeoffs and a request for determining consensus follows.
>>>
>>> On 11/20/2020 8:56 AM, Don Brutzman wrote:
>>>> Meeting minutes for Friday November 20, 0800-0900 Pacific.
>>>> [...]
>>>> 3. X3D4 finalization [...]
>>>> and...
>>>>
>>>> e. Field naming reconciliation for similar/identical fields with different names
>>>>      https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#fieldNameChanges
>>>>
>>>> Tradeoff: whether streamlining and consistency outweighs backwards symmetry.  This is not a functional compatibility issue, rather where is the burden placed.  Some work is always needed to create an X3D4 player, some understanding is always needed for authors who want to use X3D3 models with X3D4.
>>>>
>>>> Perhaps related: do we need to create a set of guidelines for X3D4 support of X3D3 loading (or X3D3 browser upgrade to X3D4 support)?  We are hoping this will be minimalist or nonexistent (for example, X3D3 models cannot load X3D4 models).
>>>>
>>>> Good topic for mailing list - any opinions out there?
>>> Further insight: the essence of this issue is whether we ask browser implementers to support field flexibility (a one-time effort) or else ask HTML5/X3D4 authors to remember idiosyncratic differences in naming that, if not honored, typically fail silently (within the DOM).
>>>
>>> This issue decides how to shift a necessary burden one way or another: either additional software effort to support X3D4, versus simplified authoring of future content.
>>>
>>> Dick had an excellent suggestion that we might formalize the relationships but declaring that original/revised field names are "synonyms" in the X3D4 specification.  Seems do-able, and also ensures that updated specification-compliant software avoids any compatibility problems.  This avoids any effect on existing X3D3 models or software.
>>>
>>> Based on implementation experience, I think that synonyms are implementable without much difficulty in XML schemas/DTDs, X3DJSAIL, X3DPSAIL, X3D Validator, and a number of other converters that we maintain in Web3D open source.  I can work with the proposed change.  So the additional level of one-time effort when upgrading is not expected to be great in other emerging X3D4 tools.
>>>
>>> Emphasis on diagnostics, converters and validation, in combination with formal "synonym" status, will likely minimize any backwards compatibility issues.  The number of affected scenes in the X3D Example Archives is relatively small (perhaps dozens, definitely not hundreds, sample space 4000).  These are all diverse edge cases that can be regularized effectively, avoiding mysterious content failures in the future.  No functional changes to X3D scene graph rendering are involved.
>>>
>>> If indeed "content is king" then favoring authorability over a one-time software refinement seems like a clear priority.
>>>
>>> I continue to request and recommend this change because now is the right time for us to execute, as part of major update to X3D4.
>>>
>>> To ensure all parties are heard from, I hereby request determination of X3D working group consensus.
>>>
>>> Feedback choices for determining consensus:
>>> a. I can    work with the proposed change to refactor and normalize certain field names as synonyms in X3D4.
>>> a. I cannot work with the proposed change to refactor and normalize certain field names as synonyms in X3D4, because ___.
>>>
>>> Please submit all responses and rationales prior to next Friday's X3D Working Group meeting.  Thanks for considering the tradeoffs.
==========================================================

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