Traits¶
The v2.x family relies heavily on polymorphic Trait objects to carry typed platform and component facts. That gives the model flexibility across registries and hardware classes, but it also means the deserializer has to decide what a trait means before it can choose the correct ASN.1 encoding.
Resolution priority¶
When deserializing a Trait, paccor tries to identify it in this order:
- By ID — match
traitIdOID against known types. - By Alias — match a registered value-property name such as
pen,bool,utf8, or another supported alias. - By Category — match
traitCategoryOID if neithertraitIdnor an alias resolved the type.
In practice, explicit traitId is the clearest option when you are writing manifests by hand, alias-based traits are the most concise option when the registry already defines a well-known value type, and category-only resolution is the fallback that keeps minimally annotated manifests usable when the category is enough to infer the trait shape.
Standard properties¶
| Property | Required | Notes |
|---|---|---|
traitId |
optional | OID identifying the trait type. |
traitCategory |
optional | OID for the trait category. |
traitRegistry |
optional | OID for the registry. |
description |
optional | UTF-8 string. |
descriptionURI |
optional | IA5 string URI. |
traitValue |
fallback | Used if no alias property is present. |
See the Trait global ASN.1 type entry for the registered alias list and type-specific notes.
Examples¶
Authoring guidance¶
Prefer explicit traitId when precision matters. Prefer aliases when you want shorter manifests and you already know the registry-specific value type. Use category-only as a fallback.