See ^^^ 4 lines up it says we have a field named TraceFlags. I'm clarifying that it's not real. It's conceptual, and it's actually encoded in the (undocumented here) field named Flags.

I'm clarifying that it's not real.

I am not sure I agree with that. It seems pretty real from data model perspective. In the data model we do have a TraceFlags field, as real as it gets in data models. The fact that OTLP uses a Flags field to encode this information is not important from the perspective of this document.

It seems we are bringing the implementation details of OTLP into the data model doc and I don't understand why.

My intention here was to clarify what may be internal confusion of mine -- I was recently surprised to learn how the W3C Trace Context defines propagation of unknown flags. Specifically, participants MUST zero the flags they do not recognize. I bring this up because the link on "as defined in W3C Trace Context" links to an overview section, whereas if you read https://www.w3.org/TR/trace-context/#other-flags you may question what it means to be "as defined in". It looks to me that if any flag besides the two we know about (Sampled, 0x1 and Random, 0x2) makes an invalid trace flags value, and perhaps the data model should say something about this.

However, my only intention was to be very clear that if TraceFlags arrives as a string like "ffff" we do not consider it valid TraceFlags, because it is too wide. I think we mean "syntactically defined as trace flags are defined" but that we are not forbidding legacy logs formats from creating logs data with unrecognized flags set as I speculated about above.