Relax EBNF restriction for selectors?

[stasm]

According to the EBNF, message references, variant expressions nor attributes of public messages cannot be used as selectors:

fluent/spec/fluent.ebnf

Lines 70 to 74 in 589a7e9

	selector-expression ::= quoted-text
	| number
	| external-identifier
	| private-attribute-expression
	| call-expression

OTOH, attributes of private messages can be used as selectors because that's how we can allow choosing the right variant for genders etc. (encoded as attributes). Attributes of private messages are language-specific which means that localizers can add any number of them to private messages.

These facts combined, it's possible to work around the EBNF like so:

-brand-name = Firefox
    .hack-message-reference = { foo }
    .hack-variant-expression = { -brand-name[genitive] }
    .hack-public-attribute = { bar.label }

hack-demo =
    { -brand-name.hack-message-reference ->
       *[Foo] I used { foo } as the selector!
    }

Should we relax the EBNF?

[stasm]

CC @Pike @zbraniecki @flodolo

[Pike]

How much overlap do we have between this and #80? Do you have a use-case in mind for this?

If this is just about being consistent, are there use-cases for non-simple attributes on private messages? Maybe the way to fix the inconsistency could also be to restrict attributes on private messages to simple string values?

[stasm]

How much overlap do we have between this and #80? Do you have a use-case in mind for this?

I don't see much overlap. Also, I don't have concrete use-cases; I was writing tests for projectfluent/fluent.js#130 and I realized it was possible to work around the restriction.

Restricting attributes on private messages would also solve this, thanks. I don't see use-cases for non-simple values.

[stasm]

This is being discussed as part of #97.