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

Sun Nov 29 08:59:49 PST 2020

One could use configuration property(s) in X3DJSAIL to configure whether to
throw an exception when an old name is used, log the use of an old name,
accept, ignore, etc.

I'm only primarily concerned with X3DJSAIL.  Other APIs can do something
different.

John

On Sun, Nov 29, 2020 at 10:37 AM John Carlson <yottzumm at gmail.com> wrote:

> One danger is the people won’t migrate from the old names.   One should
> use the word deprecated and issue warnings when old names are used.
>
> On Sun, Nov 29, 2020 at 10:23 AM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
>>
>> Date: Sat, 28 Nov 2020 12:13:37 -0800
>>> From: Don Brutzman <brutzman at nps.edu>
>>> To: X3D Graphics public mailing list <x3d-public at web3d.org>
>>> Subject: Re: [x3d-public] X3D4 finalization endgame: Field naming
>>>         reconciliation as synonyms
>>>
>>> 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
>>> >
>>> > a. Prose in Lighting and Shape components
>>> > b. Lighting values greater than 1, should we explain?
>>> > c. outlining then drafting Annex M, HTML5 Integration Guidelines
>>> > d. XSLT cleanup to remove all editorial markup and create pristine
>>> votable CD text
>>> >
>>> > and...
>>> >
>>> > e. Field naming reconciliation for similar/identical fields with
>>> different names
>>> >  ??
>>> https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#fieldNameChanges
>>
>>
>> Not sure about the GeoLOD containerField suggested change since children
>> is an output only field.
>>
>> As https://www.web3d.org/x3d/content/X3dTooltips.html#GeoLOD notes, the
>> children field should _not_ be specified. children can only be provided by
>> the childnUrl fields.
>>
>>
>>> >
>>> > 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.
>>>
>>
>> We came across the same issue with the introduction of the "visible"
>> field because x3dom already has the equivalent "render" field. "render" is
>> now supported as a synonym to maintain backward compatibility. But it
>> proved harder to implement as first envisioned. A few questions arise:
>> Should changes to one reflected in the value of the other ? (Yes,
>> immediately) Should both be able to be used in the same scene ? (Yes.) For
>> the same node, interchangeably ? (Yes.)
>>
>> This required quite a bit of refactoring, probably because the code base
>> did not anticipate synonyms. So I would encourage to favour breaking of
>> backward compatibility whenever possible, eg. for less used nodes, in
>> extended profiles.
>>
>>
>>>
>>> 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 ___.
>>>
>>
>> It depends on the field. see above. Best, -Andreas
>>
>>
>>> 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
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Sat, 28 Nov 2020 21:21:32 +0100
>>> From: Christoph Valentin <christoph.valentin at gmx.at>
>>> To: John Carlson <yottzumm at gmail.com>
>>> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>,
>>>         andreasplesch at gmail.com
>>> Subject: Re: [x3d-public] Fwd: ProtoInstance USE without name
>>> Message-ID:
>>>
>>> <trinity-271d480d-0731-4592-889d-a92f03da8b1d-1606594892166 at 3c-app-gmx-bap45
>>> >
>>>
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>> An HTML attachment was scrubbed...
>>> URL: <
>>> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20201128/68a7409e/attachment.html
>>> >
>>>
>>> ------------------------------
>>>
>>> Subject: Digest Footer
>>>
>>> _______________________________________________
>>> x3d-public mailing list
>>> x3d-public at web3d.org
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>
>>>
>>> ------------------------------
>>>
>>> End of x3d-public Digest, Vol 140, Issue 79
>>> *******************************************
>>
>>
>>>
>>
>> --
>> Andreas Plesch
>> Waltham, MA 02453
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20201129/7f99dcac/attachment-0001.html>