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 CesiumGS/3d-tiles#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.

[javagl]

Triggered by a comment in another issue: This could become increasingly important. Without any rule or resolution here, there will be extensions and clients that implement them, with little room for changing the attribute names after the extension was published/merged. So this should be resolved rather sooner than later.

The question still is: How will it be resolved?
^{(I'm better at pointing out problems than at solving them 😅 )}

I could hardly think of any sensible solution, except for prefixing the semantics with the extension name - we simply do not have any uniqueness guarantees beyond that name.

So while it's probably fine to refer to the names as _EXAMPLE_{n} during the proposal/discussion phase, they should be disambiguated when the extension is about to become "Complete" (and receives its final name). So eventually, these attribute sematics should become _EXT_the_extension_EXAMPLE_{n}.

Details:

• It will probably still start with an underscore (at least, the validator is checking that, and I think that it makes sense to keep that rule)
• I checked: The semantic names apparently can contain lowercase letters (although "all upercase" seems to be more common until now)

Some discussion points:

• What do we want to do with existing/open extension proposals that are not yet merged? (I can skim over the open PRs if necessary, to see how many of them actually define attribute semantics)
• Should we care about the case where attributes are meant to be shared between extensions? Like two extensions EXT_temperature_producer and EXT_temperature_consumer that both want to provide/access a shared _TEMPERATURE attribute?
• Did I overlook something obvious here?

---

I did start a more elaborate description of the extension development process (quite a while ago now), and information about how this issue is resolved could fit into the Technical/Naming section.

[DRx3D]

@javagl : Do you have a idea for where a naming "committee" would reside. I can envision several different kinds of structures. I think one with the most transparency and least overhead would be best, but I am not sure how to measure either criteria at this time.

[lexaknyazev]

First of all, the validator is never an authority. It's just a tool that could be changed at any time.

It will probably still start with an underscore

Reviewing this area again, it's not that obvious. The base spec:

• defines a set of base attributes and allowed accessor types for them;
• defines that application-specific attributes must start with an underscore;
• explicitly mentions that extensions may define new attributes and/or extend accessor types for existing attributes.

So it's clear that extensions can define new attributes not starting with an underscore. Besides, it would be easy to use that starting underscore character to differentiate between attributes with a well-defined meaning and restricted to specific accessor formats and out-of-scope attributes not intended for interoperability.

For example, an app currently may use an attribute named _EXT_foo_id without implying the EXT_foo extension existence; also note that the potential extension may actually be called EXT_foo_id, so there is yet another layer of ambiguity here.

So I propose leaving the attributes that start with an underscore for app-specific purposes only.

---

To disambiguate cases where one extension name is a substring of another extension name, a delimiter is needed between the extension name and the attribute name. Something like / or : would work well because these characters are commonly used for splitting the scope and are not expected to be found in extension names (: may be better because it does not interact with JSON Pointer syntax).

---

Should we care about the case where attributes are meant to be shared between extensions? Like two extensions EXT_temperature_producer and EXT_temperature_consumer that both want to provide/access a shared _TEMPERATURE attribute?

Yes. There are several ways of handling this:

• Put the attribute definition into a separate extension and make both producer and consumer extensions depend on it.
• Put the attribute definition into the producer extension and make the consumer extension depend on it or vice versa.
• Put the attribute definition in both extensions and use either. A mesh primitive can even list both names pointing to the same accessor for extra compatibility.

All these options are within the scope of extensions and do not need any extra spec support.

[javagl]

So it's clear that extensions can define new attributes not starting with an underscore.

That answers my question from the first post:

Can extensions define custom attributes without the _ underscore?

But that the aspect of the names for extension-defined attributes is not made explicit (enough)

---

For example, an app currently may use an attribute named _EXT_foo_id without implying the EXT_foo extension existence; also note that the potential extension may actually be called EXT_foo_id, so there is yet another layer of ambiguity here.

Yes, an attribute name EXT_foo_id in an extension that is called EXT_foo_id would essentially be an "empty" attribute name, which probably shouldn't be allowed. Covering this (and the case where one extension name is a substring of another extension name) with some delimiter probably makes sense.

(I'm starting to wonder whether the attribute names should have been more constrained right from the beginning. We could have attribute names like "file://A\/B@C❤;DROP TABLE students". At least, I think that JSON itself is very (too) permissive here...)

---

I don't have a strong preference for the "shared attributes" issue right now. But both introducing a new extension and establishing a dependency from one extension to the other sound like they could involve some undesired connection and overhead. So maybe the third option can be fleshed out a bit more, or maybe there can be a solution that only establishes a special naming scheme for this (probably rare) case.

[lexaknyazev]

But that the aspect of the names for extension-defined attributes is not made explicit (enough)

Yes, this should be clarified in the base spec.

whether the attribute names should have been more constrained

FWIW, a string is just a sequence of Unicode code points that could be seen as arbitrary integers. As long as the delimitation between extension and attribute names is well defined, actual substrings are not very important from the specification point of view (this surely does not mean that such names should include SQL commands).

some undesired connection

I wouldn't call it undesired given that both of those hypothetical extensions intend to refer to the same attribute semantic.