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

[John Carlson]

I think it's more critical when both oldName and newName exist in XML or
VRML (in JSON, last takes precedence, I think). Which value do you put
store last when both the new and old attributes are specified in XML?
 Some kind of ordering will exist in the tools processing the XML, but
without a standard, there may be alternate implementations.

Thanks,

John

On Sun, Nov 29, 2020 at 11:21 AM Don Brutzman <brutzman at nps.edu> wrote:

> On 11/29/2020 8:02 AM, John Carlson wrote:
> >
> > 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.
> Not sure what you mean by synonym group, haven't defined that.  There is
> no plan or need for multiple synonyms.
>
> The specific list of potential field synonyms that are identified:
>
> * X3D Scene Authoring Hints, 🔖 Potential future changes for improved
> consistency of field names
>
> https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#fieldNameChanges
>
> The design assumption that only a single field exists, as before, but it
> might now have a synonym name.
>
> So, for example, please consider the following utility methods. I'm not
> seeing any kind of data-consistency problem arising like what you are
> describing above.
>
> Example implementation approach for get/set accessor methods:
>
>         public void setNewFieldName (SFInt32 newValue)
>         {
>                 setOldFieldName (newValue); // pass value in
>         }
>
>         public SFInt32 getNewFieldName ()
>         {
>                 getOldFieldName (); // pass value back out
>         }
>
> Similarly, for a CADFaceObject (which has no other children field) this
> pattern would look something like:
>
>         public void setChildren (SFNode newValue)
>         {
>                 setShape (newValue); // pass value in
>         }
>
>         public SFNode getChildren ()
>         {
>                 getShape(); // pass value back out
>         }
>
> I think these illustrate that a pair of methods for each field synonym
> reaches minimum level of code support needed for synonym functionality,
> likely for any scene graph operations including parsing.
>
> Sample pseudocode for a parser that optionally wants to provide helpful
> warning about erroneous duplication when loading a file:
>
>         if (thisParsableNode.hasDataOldName() and
> thisParsableNode.hasDataNewName()) // optional error checking
>            print ("Duplicate field definition encountered in erroneous
> model file using old and new field name synonyms...");
>
> Alternatively an existing library that able to load files might instead
> choose to do nothing to change their parser. As typical for X3D, browsers
> are not required to report errors (default error response is undefined).
> So if a model file erroneously had two values for a single field and the
> parser just loaded one of them, or silently loaded the second value right
> on top the first, that would be an allowed response.
>
> This example approach seems pretty minimalist.  Each implementation can
> vary as they see fit, but so far synonyms seem simple to implement.
>
> Hope this pseudocode helps.  Any other use cases for codebases not covered
> here?  Further checkpoints welcome.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20201129/f6023c4d/attachment.html>