Accept attributes design & remove spec note

[eemeli]

Closes #642

Following the acceptance of the "Expression Attributes" design yesterday, this notes that approval in the doc, and updates the attributes accordingly so that they have no runtime impact.

A separate PR adding contextual u: options will follow.

[aphillips]

Good start. Thanks for saving me some work 😉

A few comments.

[aphillips]

This might be too broadly stated, since the purpose of attributes might be the "processing" of a message (as, for example, in tools).

If we wanted to prevent attributes from having an effect, we'd be better off to say that implementations must not/should not expose attribute values to functions (if functions can't see the attributes, they can't do anything with them)?

Perhaps:

Suggested change

	_Attributes_ MUST NOT affect the processing or output of a _message_.
	_Attributes_ have no effect on selection or formatting in a _message_.

... and perhaps adding:

Implementations MUST NOT pass attributes to functions.

[eemeli]

I think we need a slightly wider ban than attributes' visibility to functions, to prohibit e.g. the formatted parts representation of a message from reflecting attribute values.

Would this work?

Suggested change

	_Attributes_ MUST NOT affect the processing or output of a _message_.
	_Attributes_ MUST NOT have any effect on the formatted output of a _message_,
	or be made available to function implementations.

[aphillips]

I suggested a no-MUSTard version in part because I don't know all the use cases that an expression attribute might be put to and in part because I don't know how to test it. If an implementation decided to support some magical attributes, how would it be harmful if (for example) they affected the formatted parts? We don't define any expression attributes, so we could leave it up to implementations to decide what they mean. The statement I suggest should guide implementers away from using attributes as some sort of option factory.

[eemeli]

If an implementation decided to support some magical attributes, how would it be harmful if (for example) they affected the formatted parts?

The MUST NOT establishes a promise that when a message is being processed for formatting only, all of the attributes can be trimmed out. This allows for potentially very verbose content to be included in attributes, given that doing so has no impact on the runtime size or parsing requirements.

Without the mustard, it is much more difficult to make this guarantee, as tools can't be certain about what they can and cannot trim out. It would also significantly fuzzify the boundary between "options" and "attributes", if they can have the same effect.

[macchiati]

So @Locale=fr cannot be an attribute, right? Because it would affect the results of formatting.

It sounds like 'attributes' are really something like 'metadata'

[macchiati]

Ah, sounds like u: options now handle cases like locale settings?

[eemeli]

So @Locale=fr cannot be an attribute, right? Because it would affect the results of formatting.

That's right.

It sounds like 'attributes' are really something like 'metadata'

Yes. I would be entirely happy with renaming them as metadata, in case there's a sense that that would make it clearer.

Ah, sounds like u: options now handle cases like locale settings?

Yes, PR #846 introduces a u:locale option for just that.

[aphillips]

You removed the possibility that an attribute can have a variable as its value. Why? I agree that passing a variable might not be that useful (given the restrictions we are placing on attributes). But a use case might be found in tooling that uses the resolved value of some variable to assign an attribute value. For example, it might be used to set a debug level:

You have {$foo :function @debug=$debugLevel}

[eemeli]

Variable values are removed because that's a part of the design we accepted: https://github.com/unicode-org/message-format-wg/blob/main/exploration/expression-attributes.md#attributes

[aphillips]

Okay. I missed that part. The design doesn't say why they were dropped. I want to understand your reasoning.

[eemeli]

Ah. That comes from the first paragraph of the Proposed Design:

Provide separate solutions for attributes that impact formatting, and those which do not, so that their namespaces are not comingled.

From that starting point, the u: options have runtime impact, while @ attributes do not. Therefore, if it's not possible for @ attributes to do anything during formatting, it does not make sense to allow them to have variable values, reading which could be externally observable and could generate errors. Especially as the use cases @ attributes are serving are all non-runtime ones, which do not have access to variable values.

[aphillips]

... and results in a Data Model Error?

[eemeli]

This is using the same language we have for options:

message-format-wg/spec/syntax.md

Lines 580 to 581 in 4514e88

	Each _option_'s _identifier_ MUST be unique within the _annotation_:
	an _annotation_ with duplicate _option_ _identifiers_ is not valid.

The Data Model Error for invalid content is already mentioned here:

message-format-wg/spec/syntax.md

Lines 90 to 94 in 4514e88

	A _message_ is **_<dfn>valid</dfn>_** if it is _well-formed_ and
	**also** meets the additional content restrictions
	and semantic requirements about its structure defined below for
	_declarations_, _matcher_ and _options_.
	Attempting to parse a _message_ that is not _valid_ will result in a _Data Model Error_.

But we do indeed need to add a note to the above pointing here as well.

[catamorphism]

Looks consistent with what we agreed on.

[aphillips]

This was approved in the 2024-08-20 telecon, but not merged then due to a conflict resolved in f7b75fc. Merging now.