Proposal: Valid MF2.0 strings must end with a '}'

[SimonClark]

Currently the spec for MF2.0 specifies that whitespace outside of the curly brackets is inconsequential.

However, it may be valuable in many deployments to be able to rapidly tell the difference between plain strings and MF2.0 strings. If the spec requires that the last character be the closing curly bracket, then, regardless of the length of the string, most plain text strings can de definitively determined to not be MF2.0 by checking a single character. If the character is } , then further, more costly checks can be done to confirm it is valid MF2.0.

There should be no reason to have anything after the closing bracket, as it cannot have an effect on the output at that time.

[stasm]

I'm not opposed to this, but I also rather like that today we're keeping the syntax open to extension in the future on both sides of the braced-delimited patterns.

For instance, in #275 (comment) I imagined (in an older syntax proposal) that we may want to add new syntax to MF2 in the future to express the metadata about a message and put it after the last when:

match {$count :plural}
when 1 {You have one notification.}
when * {You have {$count} notifications.}
# What if in the future we want to put metadata here prefixed with a hash?

Or, in #287 (comment) I imagined the same thing but using a new attribute keyword, also after the last when:

match {$count :plural}
 when 1 {You have one notification.}
 when * {You have {$count} notifications.}
attribute key:value

[eemeli]

One reason to explicitly allow for whitespace after the last } is that this makes embedding MF2 content easier in resource formats that may terminate a multi-line value with a newline. For example, this YAML:

key: |
  let $foo = {$bar}
  {Some {$foo} message}

parses to a mapping where the value includes a terminal newline:

{ key: 'let $foo = {$bar}\n{Some {$foo} message}\n' }

To avoid the terminal \n, it's certainly possible to use |- instead of | as the block scalar indicator, but requiring that for all MF2 values would feel pretty clumsy.

[alerque]

Lots of editors add trailing newlines even when the user isn't aware of this. Most shells will also do the same in places people aren't aware of (e.g. echo foo comes out with trailing newline). More cases arise when people use shell tooling to do things like crop out part of a file using grep or head or whatever. Especially since arbitrary amounts of whitespace are allowed between messages, not allowing trailing whitespace after the last message to parse would cause all sorts of extra hacks just to get valid messages.

[mihnita]

+1 to allowing spaces after the final }

I am even open to do that before the first {.

So basically: after trimming all spaces from the beginning and end the messages should start with { and end with }

[mihnita]

keeping the syntax open to extension in the future on both sides of the braced-delimited patterns.

I am not sure I like this idea...
After the closing } I don't like it but I might be convinced.
Before the first { kind of strongly against.
Not sure how one can do this without breaking a lot of things.

Maybe not an argument to have now, but just casting my vote on it :-)

[aphillips]

(as chair) This proposal should be considered in our next call.

(as contributor) Based on my sense of the WG and this conversation, I think it is likely that whitespace will be allowed outside the {/}, but nothing else.

[eemeli]

Noting here retroactively that we ended up concluding that whitespace is allowed after the trailing }.