[x3d-public] [x3d] Spec Comment by walroy on 19775-1: Abstract X3D Definitions - V3.3

[Don Brutzman]

[shifted to x3d-public]

Yes the abstract specification is very open-ended about such names, while each file encoding and language bindings have their own requirements and conventions.

Insofar as possible, we have made each encoding as broad as possible too.  But unconstrained unique strings are not always portable or advisable.

For example, in the XML encoding the XML data type for DEF/USE is ID/IDREF, which is a uniqueness constraint applied to NMTOKEN (name token), which has slightly different naming constraints.  Simple summary at

	X3D Tooltips: /type/ description
	http://www.web3d.org/x3d/tooltips/X3dTooltips.html#type

For another example, few people would want whitespace as part of a DEF/USE label because it will not be correctly parsed as such in the VRML97 or ClassicVRML encodings.

For another example, when an X3D scene has DEF/USE that is contained in an HTML or XML file, identical DEF names withing the primary scene and an included ProtoDeclare ProtoBody will cause a validation failure by XML Schema and XML DTD.  I'd further expect such name collisions would cause results to be erroneous if referred to by a DOM script.

For another (somewhat related) example, when converting scenes in X3D Examples archive, found that hyphen - character in scene names (or package-directory names) are undesirable because that character is a minus sign and won't compile.  Within an X3DJSAIL program, DEF/USE names themselves can include hyphen characters, and are always validated at run time using a regular expression for NMTOKEN:

public static final boolean isNMTOKEN(String value)
{
	if ((value == null) || value.trim().isEmpty())
		 return false;
	else return value.matches("[a-zA-Z_][a-zA-Z0-9_.-]*"); // NMTOKEN character regex check
}

Perhaps we should document these various restrictions more closely as part of author guidance... most are unavoidable but some improvement may be possible.

We might also tighten the abstract specification to greatest common subset... but that might not work in future encodings.  Somewhat tricky business.

As this issue occasionally comes up, a collection of best practices has gradually been built.  These are designed to allow maximum portability among X3D representations and also best comprehension by human authors.  These are quite useful and greatly improved the interoperability of scenes in the X3D Example Archives.

	X3D Scene Authoring Hints: Naming Conventions
	http://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#NamingConventions


On 8/4/2017 8:26 AM, Spec Feedback wrote:
> -- Submitter indicates that this comment may be public: *Yes* --
> 
> Comment on 19775-1: Abstract X3D Definitions - V3.3
> 4.4.3 DEF/USE semantics
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#DEFL_USESemantics
> 
> -----------------
> Subject: No general restrictions on valid DEF names
> 
> Is "197_aTimer" a valid DEF name, assuming it is unique?
> 
> In the abstract standard ISO/IEC 19775-1 the only restriction on node names
> is given by the following text: "Node names shall be unique in the context
> within which the associated DEF keyword occurs.". So according to this
> standard the example name is valid.
> 
> In the XML encoding standard ISO/IEC 19776-1, clause 4.3.4 DEF and USE
> attribute syntax (see
> http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#DEFAndUSEAttributeSyntax)
> the text states that "DEF is assigned XML type ID". Referring to the W3C XML
> specification, clause 3.3.1 Attribute Types (see
> https://www.w3.org/TR/REC-xml/#sec-attribute-types) states that "Values of
> type ID MUST match the Name production". The "name" production is defined in
> clause 2.3 Common Syntactic Constructs (see
> https://www.w3.org/TR/REC-xml/#sec-common-syn) where it can be seen that a
> name is not permitted to start with a digit, a "-", or a ".". So, we conclude
> that the example above is invalid.
> 
> In the Classic VRML encoding standard, ISO/IEC 19776-2, clause 4.3.2.7 Node
> statement syntax (see
> http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/concepts.html#NodeStatementSyntax)
> the text gives no restrictions on acceptable names. Turning to the grammar at
> Annex A.3 Nodes (see
> http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html#Nodes)
> the node name is given by the production "nodeNameId", which, in turn, has
> the production "id". This production does have restrictions on the first
> character, which cannot be, inter alia, a digit. So, once again we conclude
> that the example name above is invalid.
> 
> In the draft JSON encoding,ISO/IEC WD 19776-5, clause 4.3.2.9.1 "@DEF"
> property syntax the text simply states "The  shall be any name in accordance
> with 4.4.3 DEF/USE semantics of ISO/IEC 19775-1.". Since the "@DEF" attribute
> has the property type 'string' in JSON there is no restriction on the first
> character being a digit. This also applies to the draft JSON schema.
> Therefore, in a JSON encoded file the above example would be valid.
> 
> Since the both the XML and the Classic VRML encodings have restrictions on
> valid values for names, it would be appropriate to detail in the abstract
> standard the requirements of name values to ensure that any given name is
> valid in all encodings. Not doing this could lead to examples that could not
> be round-tripped from one encoding to another without modifications to a DEF
> name.
> 
> -----------------
> 
> Submitted on Friday, 2017,  August 4 - 4:26pm
> by walroy (walroy )
> IP: 82.31.58.84
> 
> See: http://www.web3d.org/node/1694/submission/1416
> 
> 
> _______________________________________________
> x3d mailing list
> x3d at web3d.org
> http://web3d.org/mailman/listinfo/x3d_web3d.org


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