Discussion about the expression attributes proposal

[stasm]

#458 introduced the design proposal to add expression attributes to the syntax. #473 expanded it to include more use-cases and alternatives. I'm opening this discussion to have a place to continue the conversation about the proposal.

Note

This is a GitHub discussion. Each top-level comment starts a new thread; see the Write a reply inputs below each top-level comment. Feel free to comment more than once to give other participants an opportunity to respond just to a specific point.

[stasm]

My main piece of feedback is that the document and the use-cases are written in a way that attempts to justify a particular design. We start with the idea to add new syntax, and we look for problems that we could solve through this addition. When all you have is a hammer...

I'd like to instead start with problems. I think there are a few:

1. On "tool-time", we'd like to decorate placeholders with XLIFF attributes, such as canCopy and id. These can be used by tooling to improve the authoring experience and to protect the message's structure.

2. On tool-time, we'd like to be able to add comments and sample data to input variables, to aid translators in understanding the context of their work.

3. On runtime, we'd like to be able to add the information about the locale and the direction of (3a) placeholders and (3b) spans of text.

Problem 1: XLIFF attributes

Anchoring the design in this problem can help limit the scope of the proposal. I think we should consider spannables as a solution for this problem, as they would map in the most direct manner to the actual XLIFF.

He saw his {+mrk :xliff id="m1" translate="no”}doppelgänger{-mrk}.

Problem 2: Semantic comments

In #53 we decided that semantic comments were out of scope for MF2.

Problem 3a: Runtime data about placeholders

We already have a way to decorate placeholders on the runtime: we do it via annotations by formatting functions. For the rare cases where more than one annotation would be required, we can recommend using local variables to chain multiple annotations.

{In French, “{|bonjour| :format locale=fr}” is a greeting.}

local $userName = {$userObject :person firstName=include}
{Hello, {$userName :format dir=auto}!}

In the snippets above, I’m using :format as a to-be-named built-in formatter responsible for adding the locale and direction information to formatted message parts.

Problem 3b: Runtime data about spans of text

I think we should better document the goals and the use-cases of this problem. I can see a few:

• Produce semantically correct markup, where subpatterns are correctly marked as being written in a different language.
• Help TTS systems pronounce subpatterns correctly.
• Correctly format input variables which are part of subpatterns.

One of the examples in the proposal is:

In French, “{|bonjour| @locale=fr}” is a greeting.

But this only works for simple contents with no placeholders. Instead, I think a similar approach to :xliff from Problem 1 could be applied here. Except that our current design for spans doesn’t affect their contents. Perhaps that’s something to reconsider? Or instead, something to leave to layers consuming the parts?

[stasm]

The proposal currently states:

Define the meaning and supported values of some expression attributes in the specification, including at least @dir and @Locale.

Would it also be possible to register custom attributes in the registry?

[aphillips]

Presumably this would depend on the fate of namespacing?

I like the idea of having XLIFF or ITS attributes available, but not of requiring every implementation to support them. I think namespacing them and allowing users or implementations to plug them in would be better, e.g.:

{{The word {|bonjour| @its:translate=no} means 'hello'}}

We should only build-in the things that implementations are required to support. That has to be pretty minimal.

[stasm]

As always, I'm also concerned about adding a new sigil to the syntax. With some of the recent syntax changes proposals, we're potentially looking at things like #match {$var :func opt=val @attr=yes} being valid syntax.

Individually, a decision to add a new sigil is often well justified. However, we have an opportunity (and a responsibility!) to look at the syntax holistically and prevent it from becoming too cryptic due to a heavy use of sigils.

Because the proposal currently suggests adding @, I'd like to make sure we've explored alternatives well and even considered cutting scope, before accepting it. See my above comment for possible solutions to each of the problems that I see, as well as the function chaining alternative in the doc.

[aphillips]

These comments are all good, but isn't this what the design doc and its PR are for? Do you think it's too difficult to make these comments on that draft?

[stasm]

We merged the original PR, and the one that's currently open is about just a slice of the whole design. I think I can work my two latter comments into the doc itself, but the top one is a general comment about the doc and the problem it attempts to solve.

[aphillips]

I see the issues you refer to and in general agree with your observations. It would be hard to try to PR that into the existing doc. Perhaps a parallel doc. We should discuss with @eemeli