Purpose of the TEI

[oej]

@ppkarwasz :

As I mentioned during the workshop, I’m still unclear on the purpose of TEI types—specifically, why they impose a fixed syntax on the identifiers that manufacturers can assign within their own namespaces.

PR #187 reinforces this confusion. It states:

The user needs to get the TEI from the manufacturer, through a reseller or directly. The TEI is defined by the manufacturer and can normally not be derived from known information.

If consumers cannot derive a valid TEI from other known information (such as an SKU), then what benefit does a restricted TEI type like sku offer?

Wouldn’t it be more flexible and future-proof to define TEIs more generically, for example:

urn:tei:<domain_name>:<unique_identifier>

This approach gives manufacturers full control over their identifier format without requiring consumers to interpret or construct them based on predefined types.

Rethinking the Role of TEI Types

Rather than using TEI types to enforce syntax rules on manufacturer identifiers, we might consider using them to indicate the kind of object being referenced in the TEA service. For instance:

• urn:tei:product:<domain_name>:<unique_identifier> – refers to a TEA product, with identifier format left to the manufacturer’s internal systems.
• urn:tei:component:<domain_name>:<uuid> – refers directly to a TEA component, potentially used in SBOMs to point to upstream supplier data.

This would make TEI types more meaningful in the context of TEA object resolution, without unnecessarily constraining identifier syntax.

Originally posted by @ppkarwasz in #188

[oej]

I don't see any use cases for discovery of components, that would break the assumptions we have today.

I also like the ability to add some syntax checking by using types - not for all types - something that will make life easier for the users, which is important in this phase.

[ppkarwasz]

I don't see any use cases for discovery of components, that would break the assumptions we have today.

I believe there's a strong use case: referencing upstream security documentation in an SBOM.

In CycloneDX/specification#634, you suggested using TEIs in SBOMs. Since TEIs only point to TEA Products, dealing with large upstream projects like Apache Camel—a collection of hundreds of individual JARs—becomes problematic.

If a downstream product uses just one Camel component, you have two imperfect options:

• Reference the entire Apache Camel TEA Product in your SBOM and hope the TEA client can somehow infer which component is relevant.
• Create a separate TEA Product for each Camel component. But this clutters the user experience, especially in interactive TEA clients that show product lists per vendor.

[oej]

Great catch! But can't we add a "product" that only contains this component in that case. Like we have in the picture for Dependency Track - one "bundled" product and two products for frontend and backend?

[ppkarwasz]

We certainly can, but this raises the question about how the /products endpoint is intended to be used.

If a user wants to browse available products from a manufacturer, they'll be presented with a very long list—and even filtering by name won't be particularly helpful, since all entries would begin with something like "Apache Camel".