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

Sun Nov 29 08:22:10 PST 2020

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20201129/7e80ef71/attachment-0001.html>