Remove expression attributes from the data model

[stasm]

A follow-up to #620.

Expression attributes were proposed in a design doc, which was deemed out of scope for LDML 45. Instead, we decided to reserve the most likely syntax for the; this was done in #592.

That PR reserved the syntax, but also added attributes as a concept in the data model. I think that's wrong and I'd like to suggest to remove expression attributes from the data model.

Our formatting spec explicitly states that the reason for reserving attributes was to be able to perform syntax validity checks:

Attributes are reserved for future standardization. Other than checking for valid syntax, they SHOULD NOT affect the processing or output of a message.

Furthermore, our stability policy doesn't guarantee anything about the data model:

Updates to this specification will not change the syntactical meaning, the runtime output, or other behaviour of valid messages written for earlier versions of this specification that only use functions and expression attributes defined in this specification. Updates to this specification will not remove any syntax provided in this version. Future versions MAY add additional structure or meaning to existing syntax.

Interestingly, the policy mentions attributes by name, which I'm also fixing in this PR. The mention was added in #472 together with the rest of the wording of the policy; a mere month after attributes were first proposed in a doc.

[eemeli]

Expression attributes were discussed on the 8 Jan call, when we agreed to specifically reserve only their formatting runtime meaning. The meeting notes do not appear to have explicitly captured it, but the discussion did include the data model, where they were kept; this is noted in the subsequent PR #592.

[stasm]

Hmm, that's different from what I remember, but I may be wrong. My understanding was that there was no agreement about whether they're buildtime-only, runtime-only, or both, which is what made us only reserve the syntax.

Also, the last comment in the meeting minutes reads (emphasis mine):

APP - we will incorporate syntax for attrib as reserved, on expression and markup and make them currently explicitly not do anything at runtime. Reserved for future standardization. You do not error on them, you do not do anything with them.

[aphillips]

I think we need to fix the dangling reference in the stability policy, but otherwise forego this change? See comment.

[stasm]

There have been a number of developments since I originally filed this PR:

• Add data model to stability policy #643 make some guarantees about the stability of the data model; they are less strict than the guarantees about the syntax.
• Clarify the data model introduction #644 defines the goals of recommending a canonical data model.
• Make arrays in the data model not optional #633 now explains the differences between the canonical data model and the JSON and XML serializations of it.

In light of these, I think we should keep the attribute field, but change its type from the concrete Attribute interface to something similar to UnsupportedAnnotation.

The interface is currently defined as:

interface Attribute {
   name: string;
   value?: Literal | VariableRef;
}

If in the future we decide to un-reserve attributes, we will be constrained by this exact data model, by our stability policy. Alternatively, we will add a new interface, under a new name, since Attribute will already be taken.

Instead, we should now start with a generic representation of the reserved syntax for the purpose of the round-trip, and add the proper Attribute later on, if ever.

// Now:
interface LiteralExpression {
   type: "expression";
   arg: Literal;
   annotation?: FunctionAnnotation | UnsupportedAnnotation;
   attributes: UnsupportedAnnotation[];
}

// Maybe in the future:
interface LiteralExpression {
   type: "expression";
   arg: Literal;
   annotation?: FunctionAnnotation | UnsupportedAnnotation;
   attributes: Attribute[] | UnsupportedAnnotation[];
}

[eemeli]

If in the future we decide to un-reserve attributes, we will be constrained by this exact data model, by our stability policy. Alternatively, we will add a new interface, under a new name, since Attribute will already be taken.

Given that attributes are defined in the syntax as

message-format-wg/spec/message.abnf

Line 45 in 0c1d40a

attribute = "@" identifier [[s] "=" [s] (literal / variable)]

what would be the benefit of defining attributes differently in the data model? I don't really see how we might end up with a different representation, given that we're constrained here by the syntax.