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

[John Carlson]

One thing I am fearful of for our users is that they use multiple synonyms
within a synonym group, and expect that different field values won’t get
overwritten.

John

On Sun, Nov 29, 2020 at 9:52 AM vmarchetti at kshell.com <vmarchett.com> wrote:

> Answering the question as posed:
>
> > Feedback choices for determining consensus:
> > a. I can    work with the proposed change to refactor and normalize
> certain field names as synonyms in X3D4.
> > (b). I cannot work with the proposed change to refactor and normalize
> certain field names as synonyms in X3D4, because ___.
>
> I will answer a, I can work with the proposed change.
>
> I will recommend against the addition of the concept of synonyms into the
> v4 spec. The proposed change, at least in case of the CADFace node, is
> quite easy to describe: the field that in v 3.3 is called 'shape' will be
> called 'children' in v 4, with otherwise the same meaning and restrictions
> applied to the value of this field. It is probably a very simple change to
> make in in implementation code. Adding a new concept of synonym, alias, or
> dialect saddles our browser implementers with a new implementation
> challenge.
>
> We should not hide the fact that changing the name of a field breaks
> backward compatibility, which I define as requiring that a X3D file valid
> under version 3.3 does not become invalid when when the only change is that
> the version specifier in the header is changed to 4.0 . Breaking backward
> compatibility defined in this strict way is not a capital offense, and
> probably has already occurred in the history of the X3D specification.
>
> However, breaking backward compatibility does have implications for both
> authors and implementors. Besides deciding when to roll out X3D content
> that uses new capabilities such as physically based rendering, they also
> need to decide when to change the names of the fields in what is otherwise
> valid X3D 3.3 content. Speaking as a content producer, my decision will be
> to stop using the CADGeometry component until explicit demand from paying
> clients requires me to make the change.
>
> Vince Marchetti
>
>
>
>
> > On Nov 28, 2020, at 3:13 PM, Don Brutzman <brutzman at nps.edu> 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
> >> 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
> >> 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
> >
> > _______________________________________________
> > x3d-public mailing list
> > x3d-public at web3d.org
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> _______________________________________________
> 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/f2c95b21/attachment.html>