Disambiguation of attribute semantic names

[javagl]

The (Meshes) Overview section of the specification says

Application-specific attribute semantics MUST start with an underscore, e.g., _TEMPERATURE

Some questions are not sufficiently answered by this.

---

The first question is very vague and hard to answer specifically: What constitutes "application-specific"?

---

A broader, more specific, and somewhat crucial question is: Is it possible to disambiguate custom attribute names in extensions?

For example, there could be two extensions that both define a generic attribute name like _ID or _VALUE. The name clash would prevent the extensions to be used at the same time. A seemingly simple and straightforward solution would be to require the attribute names to be prefixed with the extension name. Something like "_EXT_foo_bar_ID" looks a bit odd, but is as unambiguous as it gets. In any case: Only requiring the undescore prefix may not be sufficient (also because there is no way to sensibly figure out which extension might already use which attribute names).

---

A question that is somewhat tangential, but brought up this one (via https://github.com/CesiumGS/3d-tiles/issues/611 ): Can extensions define custom attributes without the _ underscore?

Based on my understanding, the answer to this is no: The validator dedicatedly checks for the semantics that are defined in the core spec, and only skips the ones that start with an undescore, via the checkAttributeSemanticName function, causing a MESH_PRIMITIVE_INVALID_ATTRIBUTE error for all unknown attribute names that do not start with an underscore. But I wanted to ask for a confirmation here: Is it correct that such attribute names would be considered as invalid even when the support for the extension was added to the validator?

[lexaknyazev]

Excellent question. I think it's a case where the spirit and the letter of the spec have slightly diverged. The underscore attributes are akin to extras properties - with no portability or scope protection guarantees. At the same time, we probably cannot allow extensions to add custom unprefixed attributes for the reasons mentioned above.

[javagl]

^{Disclosure: I'm an 'Independent Contributor' for the Khronos Group, and been involved in the development of glTF extensions as part of my freelancing work, for a company that is also a Khronos member. I do not endorse or promote these extensions in my role as a Khronos contributor. They are only examples of cases where the question about the 'Disambiguation of attribute semantic names' is relevant. But the question refers to the glTF specification in general, and is not specific for these extensions.}

Two extensions are currently proposed (as pull requests) that make heavy use of glTF attributes for storing 'binary data':

• The EXT_mesh_features extension allows storing unique identifiers for each vertex of a mesh, using a "feature ID attribute". The name of these attributes are currently defined to be _FEATURE_ID_{n}. Another vendor could propose a different extension, and also require an attribute name _FEATURE_ID_{n}, meaning that these extensions could not be used within the same glTF asset.
• The EXT_structural_metadata extension allows storing arbitrary per-vertex 'metadata', using "property attributes". There is no predefined name pattern for these attributes (at least not beyond the constraint that they "MUST start with an underscore", as of the glTF specification). On the one hand, one could argue that the creator of the asset is responsible for disambiguation here. In practice, ambiguities may be caused when an application wants to add a _TEMPERATURE attribute as part of this extension, and another application wants to add a _TEMPERATURE attribute as part of another extension.