Fix formatting

Author: aphillips

meetings/2023/notes-2023-12-11.md

@@ -44,35 +44,57 @@ EAO - look at PR, gist link as to how it applies to CLDR data
 #557
 
 APP - Design doc on beautify contest, name for default selector. Issue open for a while
+
 APP - Temperature check on options?
 
 EAO - if dealing with numbers, we have an option comping up.  For Date comparison, treating as a string, this could work if we don’t have a date specific option.
 
 ECH - string comparison is lowest common denominator of comparison. Can always stringify and compare.
+
 APP - String is the chosen option with lack of objection
+
 EAO - calling it default is a bit misleading, Should we allow “string” to be a formatter as well as a selector. We explicitly do a format to string formatter. 
 
 #545
 
 APP - some disagreement in comments. Do we want to do this?
+
 STA - 2 reasons to open PR - 1) some implementation would choose to have a unresolved type. 2) original reason for adding this line no longer holds up. 
+
 EAO - would undefined be an acceptable value to use for this?
+
 STA - maybe, depending if undefined has a fallback option.
+
 EAO - how would MF logic detect if it is not defined
+
 STA - why would functions not see all the options passed to them?
+
 APP - removing this might be OK, take any options that fail to resolve a value, remove them.  This takes away the need for that preprocessing step. Do we need to specify with happens, or let implementations deal with it?
+
 EAO, in javascript makes custom functions harder to define. Prefer keeping language as it is. But won’t push back harder. 
+
 STA - testing custom functions across implementations may not be possible anyway. Should have access to options that user intended to pass, but didn’t resolve correctly.
+
 RGN - can’t support options that are impossible to specify.
+
 EAO - doen’t we get into a situation where the fallback value is what we end up specifying.
+
 APP - propose permitting implementation to do what it wants, remove requirement that undefined options are removed from map. Not sure how we test it.
+
 EAO - current option with removal can be tested.
+
 RGN - original point was for the collection of steps to be coherent when parsing message
+
 EAO - previous versions of spec was different wording but same effect, unspecified values would not be in map. Point was for both unspecified value and duplicate value errors get thrown. About clearly defining custom function interfaces, by assuming options would be unwrapped primitives.
+
 STA - sounds like original spec was about order, remove invalid options, check for duplicates. Now we check for duplicates, then remove invalid options. What behavior do we want.  Do we want to replicate javascript - not passing value, and passing undefined value is the same?
+
 RGN - need to be distinct from anything specifiable in message. Algorithm doesn’t make sense if there is not a way to resolve an unspecified option. Just removing step 4 doesn’t work.  We need to specify expectations of implementations.
+
 APP - try to ensure we detect duplicate options, and detect when required value is not provided. Specify case when there is a duplicate, but one value is not defined.
+
 EAO - request to STA - add a description to PR of user story arguing for use case to show value of proposal - realish scenario where leaving the value out makes sense.
+
 STA - possible use case: function requires option foo. Someone passes foo = $var. Fails to resolve. Error says foo not passed because of runtime failure. 
 EAO as long a language allows js to use undefined as sentinel value, then can support
 
@@ -92,55 +114,92 @@ Merged with consensus
 #502
 
 APP for a while. May be controversial.  Discussion now.
+
 EAO discuss later
 
 #471
 
 APP MIH had some comments. Any discussion?
+
 APP change “exact” to “string”?
+
 EAO - objects to changing to “string”, numbers are better defined from other types.
+
 APP - additional to plural. 
 Merge, and if strong feelings, create a new PR 
 Merged
 
 #438
 
 Have a missing selector annotation error already. This adds additional verbiage
+
 APP please have a look
+
 EAO if anyone is interested in championing this PR, put a comment on it by next week.  If not we close it.
 
 ## Spannables
+
 We are together of #/ for spannables
+
 \# is for both standalone and open. 
+
 STA design doc does not specify what we are trying to resolve. Should we specify that translations should include markup. Does not focus on tooling and protection. Important use cases
+
 APP spent a fair time on use-case doc.  This is a compromise syntax, where we do not accept operand on …
-APP Implementation is allowed to disintegrate these, could be used for markup, XLIF tags. Distinct from true functions. Are we close to done? How do we solve standalone problem?
+Implementation is allowed to disintegrate these, could be used for markup, XLIF tags. Distinct from true functions. Are we close to done? How do we solve standalone problem?
+
 STA - a lot of this could be left to custom functions. Function to default to empty string makes ignorable, eg. Did we focus on a solution without understanding reasons?
+
 STA standalone is key to puzzle. Do regular placeholders like $username count as standalone?
+
 APP regular functions are not default ignorable. Different from “can be filtered”  ABNF is inconsistent, has + and -
+
 APP what is the feature we are building?
+
 EAO - core use case for having proposed expression of markup is to be able to represent messages that have structure, contain spans with properties. Make sure we accurately present messages, can be formatted to parts without starting from scratch .  Well served by current design?  Come to consensus about standalone so we can merge this.
+
 APP have a bunch of interesting use cases in doc, not wrong. Namespaces for markup and templating languages . goal is to write things as naturally as possible.  Wants to get to closure to at least fix plus and minus in ABNF. Need a sigil for functions, or is two enough.
+
 STA - avoids double parsing, not mentioned in doc? Concerned we are not fixing the right problem. If we say solution has to be better than just using functions. 
+
 MIH document why we decided to not use functions. 
+
 STA if we document why decision was made, even if it is “we ran out of time”. 
+
 APP concerns about why not use functions is valid. Nothing in spec prevents it.  This gives a way to plug in support for spannable markup structure in a message without polluting function registry. Allows spannables in self contained non-function registry way.
+
 MIH - why do we not have standalones now? 
+
 APP - opener can do the work of standalone, at least for html. Need syntactically distinct standalone. Do we want 2 sigils than three.
+
 STA- would rather pollute the registry than the syntax stack. Don’t need a separate sigil. Can use #/
+
 EAO - can we explicitly conclude standalone discussion? STA review use cases, and argue if further work needed? 
+
 STA can look at use cases after christmas
+
 APP - proposal - APP goes through use cases, make summary of supported and unsupported use cases. EAO is concern that we have an open and close state for placeholders? Possible to melt spannables back into functions with sigils for open and close
+
 EAO - would rather not go back to drawing board. No convincing story for why placeholder would need an operand. Makes it significantly more difficult to tell difference between markup and non-markup condition. 
+
 STA concerned that we say we forbid operands without saying why. Why decide to go away from plus and minus? Not well documented.
+
 EAO approach from direction of starting having nothing, then having markup. Why should we have a sigil. Close to being able to complete discussion. Update use cases, agree on standalone, then lock this discussion down
+
 ECH - appreciate effort to say we need to document, then document rationale. 
+
 EAO - resolved a way to proceed with open/close syntax. Only remaining ? is if we allow different syntax for standalone vs open/close.
+
 STA - backwards. Open/close , standalone are too connected to decide one then the other. Wants to get feedback on #foo/ model. Also :html: namespace function call. Match with #html … / function call. Not sure what is better. Likes idea that regular placeholders and standalone. 
+
 EAO - observation, no matter what we decide, it will remain possible for a custom implementation/function to support {:html image}. Is sufficient to provide support for rarer use case for standalone content?
+
 STA concerned about micro ? of syntaxes.
+
 APP call out usecase satisfied by #/. Open question is # insufficient to meet standalone requirements?
+
 EAO is we do have specific spannable syntax, would prefer that they are required to pair.
+
 APP will have to have ballot in new year.
 
 ## Topic: AOB?