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

[Don Brutzman]

Worked on implementation and evaluation of these changes to field names today.

* Field name changes planned for improved consistency
   https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#fieldNameChanges

Mostly worked OK.  Found 2 nodes with proposed field changes that should _not_ proceed:

a. CADFace         /shape/ field is SFNode and so cannot be mapped consistently to MFNode /children/ (congratulations Vince!)
b. CollidableShape /shape/ field has accessType initializeOnly and so cannot be mapped consistently to MFNode /children/

... which leaves the remaining changes:

1. ComposedCubeMapTexture: make six sets of field names identical to TextureBackground for contained textures, e.g. back becomes backTexture, top becomes topTexture, etc.
2. DISEntityManager: change unnecessarily different containerField='mapping' and rename as containerField='children' instead.
3. LoadSensor: 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.
4. ParticleSystem: change unnecessarily different field names colorRamp, texCoordRamp and rename as regular defaults color, texCoord instead. Related: see issue Mantis 1322 to allow TextureCoordinateGenerator as an alternative to TextureCoordinate for that child node.

Changes applied to X3D XML Schema, DOCTYPE, X3D Unified Object Model (X3DUOM), and stylesheet tools.  Everything is checked in, distribution builds will be uploaded tonight.

Corresponding review and revisions continuing for X3DJSAIL, X3DPSAIL, X3D Tooltips and X3D Schematron.

All specification changes also checked in, Dick and I will be checking those and also confirming that a number of other Mantis issues have been satisfactorily resolved.

* https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/Architecture.html (public)

* https://www.web3d.org/member-only/mantis/view_all_bug_page.php (member-only)

Have fun with X3D4!  8)



On 12/8/2020 5:30 PM, Don Brutzman wrote:
> 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
> 
> ==========================================================

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