Skip to content

Clarify standalone vs. open vs. close function/expression #424

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
aphillips opened this issue Jul 13, 2023 · 4 comments · Fixed by #541
Closed

Clarify standalone vs. open vs. close function/expression #424

aphillips opened this issue Jul 13, 2023 · 4 comments · Fixed by #541
Labels
blocker-candidate The submitter thinks this might be a block for the next release functions Issue pertains to the default function set normative Issue affects normative text in the specification specification Issue affects the specification

Comments

@aphillips
Copy link
Member

See: https://github.com/unicode-org/message-format-wg/pull/419/files#r1262730738

In adding definitions for open and close expressions (and their friend standalone), we found that we are underspecifying them. This is a placeholder to solve that.

@aphillips aphillips added blocker-candidate The submitter thinks this might be a block for the next release normative Issue affects normative text in the specification functions Issue pertains to the default function set specification Issue affects the specification labels Jul 13, 2023
@stasm
Copy link
Collaborator

stasm commented Jul 17, 2023

For completeness and ease of viewing, here's @aphillips's comment from the review thread linked above:

In particular, the current state of our spec is that these are all the same and refer to a discrete function open:

let $foo = {$bar :open}
let $foo = {$bar +open}
let $foo = {$bar -open}

Obviously, though, +open and -open need to have a different syntactical "meaning" if the open and close expressions are to do different things (such as write open vs. close tags). The interaction with the function registry is interesting here.

@stasm
Copy link
Collaborator

stasm commented Jul 17, 2023

There are two requirements that I'd like to suggest, in line with @aphillips's comment:

  1. It should be possible to make a placeholder "open" or "close" even when it doesn't mention a function name at all.

    • Corollary: standalone/open/close are a property of the placeholder itself rather than the function's.
  2. It should be possible to define a single function in the registry (e.g. :html) and then specify its various possible signatures for formatting or matching. The formatting signatures should also define whether they're for standalone, open, or close uses.

    <function name="html">
        <formatSignature position="open">
             <!-- ... -->
        </formatSignature>
    
        <formatSignature position="close">
             <!-- ... -->
        </formatSignature>
    </function>
    
    • Corollary: +html and -html (in today's syntax) are two signatures of the same function.

These two requirements combined lead me to suspect that we should move the open/close syntax into the placeholder rather than bind it to the function name.

@eemeli
Copy link
Collaborator

eemeli commented Jul 18, 2023

I have a few thoughts on this:

  1. The exact shape of the XML doesn't really matter to me, i.e. whether signatures are nested under a single <function> or all next to each other is not important.
  2. +html and -html need to have different options baskets.
  3. It would be useful to be able to use a single definition for multiple functions. For example, +bold and +italic (or +html.b and +html.i) would probably accept the same options (if any!), along with many others. It'd be nice not to need to repeat the same thing multiple times.
  4. I would really like not needing to revisit expression syntax again.

@markusicu
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocker-candidate The submitter thinks this might be a block for the next release functions Issue pertains to the default function set normative Issue affects normative text in the specification specification Issue affects the specification
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants