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

[Don Brutzman]

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