Unifying intent

[davidcarlisle]

At the call on 2021-11-04 two intent proposals were proposed (further discussion expected this week) This issue is the start at trying to propose a unified syntax,

---

Bruce

https://mathml-refresh.github.io/discussion-papers/semantics-mini

intent   := literal | selector | intent '(' intent [ ',' intent ]* ')'
literal  := [letters|digits|_|-]+
selector := argref | argpath
argref   := '$' NCName
argpath  := '$' [digit]+ [ '/' [digit]+ ]*

Sam

https://samdooley.github.io/mathml-docs/intent2cmml/intent.html

intent    :=  {explicit} | {implicit} | {reference} | {name} | {literal} | {special}
explicit  :=  {value} '(' ( {intent} [ ',' {intent} ]* )? ')'
implicit  :=  {value} '@' | '@' {value} | '@'
reference := '$' {name} | '$' {number}
literal   :=  '#' {name} | '#'? {number}
special   :=  '!' {name} | '!' | '/' {name} | '/'
value     :=  {reference} | {literal} | {name}
name      :=  [A-Za-z_][A-Za-z0-9_.]*
number    :=  [0-9.][A-Za-z0-9_.]*

---

I suspect we don't need ! even though it may help forcing some specific content mathml forms such as <apply><plus/> rather than <apply><csymbol>+</csymbol> we can probably arrange the defaults "do the right thing" not dont need that,.

Similarly the literal prefix # is not I think needed as unprefixed names and numbers can serve this purpose. <mi intent="3">iii</mi> in Bruces's proposal seems equivalent to <mi intent="#3">iii</mi> in Sam's

The intent=/ for empty is (normally) covered by having an intent on the parent that doesn't select the element. I think remaining cases could be covered by intent=""

Bruce confirmed in the call that the omission of a syntax for implicit list of arguments was intentional but I think that (+ 1 2 3 4 5 6) becomes unweildy if we don't have this and even if we could make the default intent of <mrow>... <mo>+</mo> ... <mo>+</mo> ... <mo>+</mo> ... <mo>+</mo> ... <mo>+</mo> ... be this, we can't write down the default value explicitly if there is no syntax for narry application.

However I'm not convinced by the suggestion to allow @ on its own or suffix or prefix position, it seems sound but is very hard to remember which is which. I think I would just add one wildcard symbol @ (although * would be another possibility) to mean "all argument children" for some definition of "all".

So Sam's

<mrow intent="@">
  <mi>a</mi>
  <mo>+</mo>
  <mi>b</mi>
  <mo>+</mo>
  <mi>c</mi>
</mrow>

would become

<mrow intent="$op(@)">
  <mi>a</mi>
  <mo arg="op">+</mo>
  <mi>b</mi>
  <mo>+</mo>
  <mi>c</mi>
</mrow>

and

<mfrac intent="@divide">
  <mi>x</mi>
  <mn>3</mn>
</mfrac>

would be

<mfrac intent="divide(@)">
  <mi>x</mi>
  <mn>3</mn>
</mfrac>

where @ means (to be defined explicitly) all the non mo children.

For child references both proposals allow $3 and $foo, Bruce also allows $3/$1 but I think you could also allow $foo/$2

So... (untested by any running code...)

intent       := emptyintent | nemptyintent
emptyintent  : = ''
nemptyintent := literal | selector | intent '(' wildcard ')' | intent '(' nemptyintent [ ',' nemptyintent ]* ')'
literal      := [letters|digits|_|-]+
selector     := ( argref | numref ) [ '/' selector ]?
argref       := '$' NCName
numref       := '$' [digit]+
wildcard     := '@'

[brucemiller]

Interesting synthesis. But something went wrong with the nemptyintent production. Perhaps:

nemptyintent := literal | selector | nemptyintent '(' arglist ')'
arglist := wildcard | intent [ ',' intent]*

What does emptyintent signify? I'm guessing it makes the node invisible to AT (and defaulting)? Although I hadn't actually allowed it in my grammar, I found it necessary to allow empty intents within an arglist to signify missing or implied arguments (otherwise you'd need many special case literals for derivative, for example (though maybe there are better solutions?)).

Although I understand the appeal of implicit arglists, I'm still sceptical of the added complexity. Although it helps a+b+c...., the current proposals don't help a+b-c+d..., which are at least as common. And I've noticed that offering @ seems to tempt people to use it where they end up with various opaque tricks to make it work.

[davidcarlisle]

@brucemiller I added emptyintent as (a) you'd mentioned it on the call and (b) here I'd written that empty could be used instead of the intent="/" in Sam's grammar, so I thought I'd better allow it. It was more disruptive than I wanted as I didn't want to allow empty in the nested cases intent=divide(,,) so I had to have a nonempty production for the recursive cases.

[brucemiller]

Actually, the recursive case is exactly where I wanted to allow emptyintent (eg $f^(n)$ has intent=derivative(f,,n) ), but presumably not for the operator itself; I hadn't needed it at the top-level.

[brucemiller]

And, coming back to "implicit arguments", why does $a+b+c+d$ or $a+b-c+d$ need an intent value at all? If the goal is accessibility, in almost all cases it would be read as "aye plus bee minus see plus dee". At most, the operators might need an intent.

[davidcarlisle]

on empty oh yes so you do, OK I'll adjust,

on narry arguments I think I'd agree that special casing the case where all operators are the same is probably not right, you really want to have intent = "natural sequence of arguments and infix operators" that would anyway be the default, so then it comes down to a more philosophical design question as to whether the default should correspond to an explicit intent in all cases.

[dginev]

At the moment, I personally only see the need for a restricted subset of Bruce's grammar that holds a bare minimum for writing down

1. concept names
2. argument references
3. a minimal way to combine them together

which appears to fully suffice for AT remediation. Namely:

Deyan

intent     ::= name | expression
name       ::= concept | argref
concept    ::= [letter|digit|-]*
arg        ::= [digit]+
argref     ::= '$' arg
expression ::= name '(' intent [ ',' intent ]* ')'

with an example use:

<mrow intent="$1($2)">
  <mi arg="2">x</mi>
  <mo arg="1" intent="double-factorial">!!</mo>
</mrow>

Edit: update with a link to my group meeting talk on this approach.

Technical remarks:

• Empty intent, for silent speech, via intent="" seems reasonable, though I wonder if ARIA interop isn't a better way to allow it via aria-label="" or probably even better aria-hidden="true".
• long n-ary argument lists. Yes, the annotations get verbose. But we lack good examples where the annotations are actually needed, as the narration in arithmetic follows the presentation. I think having 3-4 good examples of n-ary arguments that really require annotation would help to understand this better.
• Ideally we can mediate some of the verbosity by having a solid baseline behavior for the raw presentation of K12 notations.

Design motivation:

In my view, having a simple and predictable (you could even say "boring") mini language, would allow remediators to spend their time thinking on the subject matter and how it should be narrated and **not** think about what would be the best way to use a very expressive specification. Similarly on the proof-reading side, if a piece of the narration is flawed due to the intent annotation itself, it should be instantly obvious where the problem is and there should be a direct intervention possible to correct the issue. This is actually the reason I preferred David's initial suggestion of using these localized `arg` attributes, as authors untrained in XML would be better at pattern-matching numbers on their screen (`$4` with `arg="4"`) than they would be with performing a tree walk and counting the various branches, plus taking the right detours. Ideally I would want to test this on actual human authors before making such a pronouncement, but in the absence of an A/B testing step in our specification process, this is my best "gut feeling" about what would be most promising to gain adoption. (what Bruce called the "market needs")

[NSoiffer]

I think we need to do something about long n-ary argument lists. Yes, defaults do take care of the ones I'm aware of, but I think it is important to be able to specify a default value as an intent value so that one can describe the defaults as an intent (basically eating your own dog food). Or more practically, not having to invent something new in software to handle the default. I envision a system to interpret intent working along the lines:

1. If intent is specified, use it
2. Look for a match in any subject-area intent "style sheets"
3. Look in the default "style sheet"

'2' or '3' might have document-level or user "style sheets" for intent in addition to whatever defaults the software has.

I'm using "style sheet" in a very generic sense of being a collection of patterns that match to return an intent value. They could be CSS-like, or they could be something very different.

[NSoiffer]

I mostly agree with @davidcarlisle about the special values being unnecessary.

@samdooley: if you have some specific use cases in mind where they are actually needed, you should add them to your doc where you introduce/explain the syntax. The examples given merely show that your statement "it is rarely needed" is true; what they don't show is that "never needed" is false.

I do see some merit in @, although (again agreeing with @davidcarlisle), it seems overly complicated. I want to come back to my favorite example: a+b-c+d (all in an single mrow) that @brucemiller brought up. If @ just meant use the arguments as is (I think * would be better), then this would speak just fine, but if it has to point to an argument and use the speech for that argument in place of all of the mos, then that doesn't work. For what @samdooley wants to do, I think the answer is that a complicated (nested) intent value is needed because the mapping between presentation and content is more complicated.

Although I complained about @ seemingly overly complicated, I want to throw out a suggestion for a complicated version that is potentially powerful, at least for speech: `prefix@infix@postfix" (prefix/infix/postfix would be given as the actual words to speak) where

1. 'prefix' would be spoken first,
2. then the first arg would be spoken
3. the remaining content would be spoken as 'infix' followed by the next argument, and so on
4. finally, 'postfix' would spoken

"prefix", "infix" and "postfix" are optional. Examples:

• intent="@@" would be used for my a+b-c+d example and other similar n-ary examples.
• intext="fraction@over@end fraction" could be used for an mfrac

I don't have a lot of good examples, so maybe this is too much complication for not much gain.

[NSoiffer]

Mainly a question for @dginev...

With your example

<mrow intent="$1($2)">
  <mi arg="2">x</mi>
  <mo arg="1" intent="double-factorial">!!</mo>
</mrow>

If the AT doesn't know about double-factorial, wouldn't the likely speech be "double factorial of x"? That's not terrible, but probably not what is intended.

My question: how do we distinguish between wanting to hear "x double factorial" and "double factorial of x"?

[brucemiller]

If we need an intent value as a place-keeper for "read the tree as it is" (ie. depth-first traversal) then we can make @ stand for that.

[dginev]

My question: how do we distinguish between wanting to hear "x double factorial" and "double factorial of x"?

Short: external speech hints via either a global list, and/or a document-level list and/or an AT-specific vendor list. As well as using AT contextual decisions.

Long:

That's not part of the main intent syntax in my current view. Mostly since my understanding is that there is broad group consensus to keep the intent values inside MathML detached from the specific language considerations of AT generating the final narration string (be it for speech or for Braille). As has also been pointed out, these considerations are different for different languages. Where I think it is *convenient* to put such information is in a public list that we had prototyped in google sheets (the "Intent Levels" lists). In particular in a column named `speech hints` (or similar), keyed after the concept name. So for this example one would add either the speech hint `$1 double factorial` or `double factorial of $1` *but only if* the distinction was important for the quality of the narration. I'm not sure it matters in the specific example. Without such special information, AT can make its own decisions, and it can take into consideration all kinds of auxiliary information, as the developers prefer. For example, it can infer this notation is postfix by examining the presentation tree, or it can make a decision based on the surrounding expression context, etc. Separately, if author-specified and/or user-specified "stylesheets" become available (e.g. as with Brian's demo use of CSS), these speech hints could be added for an individual document. That sounds advanced to me, but I'm open to seeing how the group develops document-specific stylesheets further.

[davidcarlisle]

looking at @dginev's simplification ...

I think dropping named arguments may be a step too far: allowing intent="..$foo" .. <mi arg=foo> as well as intent="..$2" ...<mi arg=2 makes some things look a bit nicer

However dropping the $2/$3 path syntax might be a good idea. It perhaps isn't needed as instead of $3/$2 you could put arg="zz" on the grandchild and replace $3/$2 by $zz As elsewhere I think its main benefit would be specifying defaults but perhaps we can work round that. If we keep it then specifying / will face the same issues that anyone accessing MathML with XPath finds; that the child step in the xml isn't necessarily the logical child and you would need to decide whether / is strictly referencing a child in the xml tree or whether you step through redundant or implied mrows. that is given

<mrow><mrow><mi>a</mi><mi>b</mi></mrow></mrow>

is b $2 or $1/2 the mathml spec has always said that such a single child mrow is redundant but if removing it means re-numbering all intent paths that's a bit of a pain.

[brucemiller]

As @davidcarlisle suggests, a main advantage of the path syntax ($2/$3 or $2/3, whichever) might be for defaulting. Think of several patterns to match the various forms of binomial (mfrac, marray,..). When defaulting matches a given pattern to a mathml subtree it could simply add the corresponding intent to the root of that subtree and be done, without having to invent names and find and modify the children.

OTOH, since it would presumably would also restrict its recursion to only those children that were referenced (ignoring children that were invisible, such as the binomial's parentheses, the mfrac itself, etc.), it would still have to find & fiddle with the children; So maybe the "simplification" of the 1st paragraph is no real advantage.

[dginev]

I think dropping named arguments may be a step too far: allowing intent="..$foo" .. as well as intent="..$2" ...<mi arg=2 makes some things look a bit nicer

They could look nicer or they could look worse, it depends on what values are used.

Long:

I am not universally against expressive syntax, e.g. I enjoy that a lot in programming languages. But for this small mini-language, you lose some predictability, and some ease of debugging, when you fully open up the arg naming. Consider the typo: ```xml x i ``` narrated e.g. `x at index index`. vs the typo: ```xml x i ``` narrated `x at index two`. When I imagine annotating and then proof-reading the narrations for an entire book, my gut feeling for restricting to only numbered refs is that people would develop a very targeted attention for the first few natural numbers (to detect typos), the sounds of the concept names, and the order of the arguments. And know anything else lies externally to their annotation - either with the enabled lists of speech rules, or with the AT developer. Debugging gets simpler when you can have fewer surprises. But again, I'm sorry I have to state this as an opinion, since the only real way of knowing is A/B testing with real human authors and publisher remediators. Edit: Though making such typos "invalid" and possible to detect automatically would be even better than training remediators to proof-read for them. I had made an early remark that if we disallowed the number literals in concept names we can drop the `$` marker entirely and reserve numbers for references - in which case `$2` to `2` is not a possible typo. And even if `$` remains required, a tool could spot `2` as invalid and suggest `$2` guarding remediators from this kind of typo. But none of that automation is possible for the `index` and `$index` combination, where each is legal and means something useful and different.

[brucemiller]

I may be missing your point, but to me your second typo seems harder to catch from the output than the first. Of course, I'm more comfortable with the pedestrian kind of mathematics that has numbers in it. Numeric literals will be needed, on occasion (eg. $f''$).

That said; automatic sanity checking would be a good thing.

[dginev]

harder to catch

Harder to notice, easier to figure out. But sure, this is why I'd lean towards automating the detection entirely, for this class of error. Spellcheckers are a huge help for text, so a good refchecker ought to be a huge help for these attributes.

My point was more focused on debugging what went wrong than about initial detection. How one names the argrefs could be a cause of confusion and surprise, in an analogous way to how one names their variables in a programming language could cause confusion and surprise. They could also be a source of great clarity when chosen judiciously, as you and David hope will be the usual case. But that optimistically assumes the remediator is in possession of that great clarity while annotating.

My intuition is that when one remediates+proofreads a book (~10,000 expressions), or a paper (~1,000 expressions), there will be a noticeable speedup from the boring predictability of only having numbers in the argument holes. Both when adding them in ("how do I name this?" is never asked), and when reading through them later ("what is this foo referring to and why did I name it foo?").

f''

I assume you mean "the second derivative of f" and not f-double-prime here. It's less obvious to me. Wikipedia has a page for second derivative, and has an alias mentioned - second-order-derivative. The appeal of derivative($1, 2) is understandable, from a computational standpoint, it's the second functional-power of the derivative. Then again, if that was the core motivation, we've also discussed that as functional-power(derivative, 2) which is what's really getting computed. Which annotation feels "natural" here depends on what one is trying to model, and I think we still lack a common vision in that regard.

[davidcarlisle]

@dginev I think my main concern is it is rather unusual to use numbers as identifiers, most (or at least some) systems force at least the first character to be non-numeric, eg the NCName in Bruce's grammar or [A-Za-z_][A-Za-z0-9_.]* in Sam's in both of those, $2 references the second child, and while we could define it as you suggest to reference whatever element has arg="2" I suspect that people will still read it as positional.

[brucemiller]

Mainly, my point was that neither names nor numbers are inherently easier to debug, depending on the accidents of the names and numbers chosen and the exact situation. And my second point, independent of the merits of any particular encoding of derivatives, was that literal numbers are almost certain to be needed somewhere.

I suppose if we drop support for the path-style references, the named references can allow any alphanumeric for the name. Then you can use pure numbers for annotation if you prefer.

Alternatively, we could use a distinct modifier prefix for path references. That has the advantage of more clearly distinguishing different kinds of reference. In an ideal world, I would have suggested '@' (with "at" suggesting "position").

[dginev]

@dginev I think my main concern is it is rather unusual to use numbers as identifiers, most (or at least some) systems force at least the first character to be non-numeric

Not my fight, but HTML5 has allowed purely numeric ids since at least 2010 if this article is right. More to the point, the arg attribute is not an identifier - we can expect hundreds of identical ones in the same document, when the same notation is repeated. It's just as soft as class="intent-arg-1".

If it's a substantial problem, I could imagine some reworking where we do away with the dedicated arg attribute to avoid the issue and instead make a heavier intent attribute, as in (for my double-factorial example): intent="arg:2", or
intent="arg:1; double-factorial", or something on those lines. Not too enthusiastic about getting in the territory of style-like values though.

[NSoiffer]

@dginev hinted at a what is likely a really useful tool: a validator that looks at the intent values in a document and gives errors and warnings.

Errors would include referencing something that doesn't have an arg that is in scope (e.g, could be missing or could be blocked by another intent).

Warnings would be for literals in the intent value that match arg values in scope. There are probably other examples that deserve warnings (e.g., referencing the same arg twice is likely a mistake).

I think with such a tool, concerns about mistakes involving numbers or alphanumeric refs being hard to spot go away. Of course, people can still make lots of other kinds of mistakes like using $2 when they really meant 2 and arg="2" actually does exist. Still, the tool would likely catch the vast majority of mistakes.

I wouldn't be surprised to see @davidcarlisle or @dginev demo such a tool next week. Hint, hint 😀

[dginev]

@davidcarlisle @brucemiller @samdooley @NSoiffer I've opend a new issue to do a deeper dive on the n-ary expressions at #253 , pinging here just in case you're not subscribed to the repository notifications.

[physikerwelt]

Just for the record:

I think introducing a new grammar to describe the intent is not a good idea at all. Overall, it seems that the majority of the group insists on adding new complexity instead of "abusing" other existing methods, as described in the Leveraging Existing Technology section of the MathML Accessibility Gap Analysis document. Since this attribute describes mathematical semantics, I think the least harmful solution was to use some form of LaTeX like syntax. At least it comes with selectors among other language features.

[davidcarlisle]

As briefly discussed on the call today, we need to get back to intent.

At

https://w3c.github.io/mathml/spec.html#mixing_intent_grammar

There are currently two versions of the grammar showing, the second one being more aggressively minimalist and is similar to @dginev 's version above in not having numeric paths or wildcards (but it does still separate out numeric literals from identifiers for the concept entries in the intent table.

I think the $4/$5 path syntax does simply describing the default intent as you can say <mfrac> has intent divide($1,$2) without having to invent a meta syntax that allows you to say divide($a,$b) where arg="a" and arg="b" added in suitable places ...

But counting elements leads to all kinds of issues around redundant mrows and which elements to count and I'm not sure the benefits outweigh the costs, or that we could get a usable version agreed in reasonable time.

So I would propose going for the minimal version which is however structured such that numeric paths could be added back later if some pressing use cases are discovered.

For the record in case the spec version gets edited, the minimal version there is:

intent   := number | NCName | argref | function
function := (NCName | argref) '(' intent [ ',' intent ]* ')'
number   := '-'? digit+ ('.' digit+)? 
argref   :='$' NCName

That is, using NCName to denote intent concepts, allowing numeric literals, not allowing empty intent or empty function parameters.

[davidcarlisle]

A comment on the minimal version of intent in the previous comment dropping numeric path references.

I think that they would be useful, especially for specifying defaults) and if we can bring them back later we may want to reconsider (which is one reason I'm not keen on allowing numeric names here). But experimenting with polyfills, they just seem too fragile.

Looking at the first example at

https://mathml-refresh.github.io/mathml-polyfills/acid-test.html

I added an intent to the <mfenced> to say it was a pair:

 <mfenced open="[" separators=";" close="]" intent="pair($1,$2)">
     <mn>0</mn>
     <mn>1</mn>
 </mfenced>

Once the polyfill is enabled so this renders as [0;1] the DOM is equivalent to:

<mrow intent="pair($1,$2)">
  <mo fence="true" data-nesting-depth="1">[</mo>
  <mrow><mn>0</mn><mo fence="true" data-nesting-depth="2">;</mo><mn>1</mn></mrow>
  <mo fence="true" data-nesting-depth="1">]</mo>
</mrow>

where the intent is now basically wrong.

We could say that is just an implemenation deficiency in the current polyfill, not fixing up intent, or we could specify that values always reference the initial document or we could say intent is only supported on core or ... but none of these choices seems particularly appealing.

Using arg references, the intent survives the mfenced polyfill, even though it was not coded to do anything special with intent

 <mfenced open="[" separators=";" close="]" intent="pair($a,$b)">
     <mn arg="a">0</mn>
     <mn arg="b">1</mn>
 </mfenced>

becomes

<mrow intent="pair($a,$b)">
  <mo fence="true" data-nesting-depth="1">[</mo>
  <mrow><mn arg="a">0</mn><mo fence="true" data-nesting-depth="2">;</mo><mn arg="b">1</mn></mrow>
  <mo fence="true" data-nesting-depth="1">]</mo>
</mrow>

[brucemiller]

Ouch! That's a pretty compellingly annoying example!

I still think that relative paths would be useful when defining defaulting patterns, but that the application of such a pattern to a given MathML fragment should convert the path references to named ones and add the arg attributes appropriately.

But relative paths are perhaps just too risky within the normal intent values.

[davidcarlisle]

@brucemiller yes that was my thought too that the polyfill could convert the paths to named references which would then survive the transformation, but the whole thing made me uneasy. If we keep the grammar so that numeric paths could be added back if they prove to be needed, going with the minimal version without them might simplify things (and we might need a simple version to get this all signed off in reasonable time)

[brucemiller]

I may have been unclear: I do not think it is wise to require the polyfill (that would, eg. convert mfenced to an mrow) to deal with adjusting references. They're hard enough already, and kind of come in from the wild. Given that, we probably should not allow relative paths in the intent attribute.

What I was tentatively and speculatively proposing was that if and when we consider a defaulting mechanism (which would likely be outside of MathML proper), we might want to have an enhanced intent minilanguage which did include relative paths. Something handwavingly like:

match_fence : pair($1,$2)

and it would be the defaulting machine's responsibility to add the intent and arg attributes to end up with your

<mfenced open="[" separators=";" close="]" intent="pair($a,$b)">
      <mn arg="a">0</mn>
      <mn arg="b">1</mn>
  </mfenced>

And then polyfills are free to mangle as they wish.

But that's all just recording a thought for the future. It's probably best that we omit the relative paths from intent for now.

[davidcarlisle]

@brucemiller ah yes having an enhanced meta syntax for describing defaults could work. I'll leave both versions in the spec for now but hopefully we can sign off the grammar on the call tomorrow, at least an initial draft stable enough to move forward with chapter 5

[NSoiffer]

Nothing like looking at examples to sharpen one's thoughts. I originally liked the idea of positional arguments, but the mfenced polyfill example shows the danger of it. Although the polyfill could be modified to deal with it, that more complication. So I "officially" change my mind and think we should ditch positional references for now.

Doesn't NCName allow for digits, so $1 would be valid in the minimal grammar? We should prevent that so that if in the future we want positional references, we can add them and not break existing usages.

[davidcarlisle]

@NSoiffer

Doesn't NCName allow for digits, so $1 would be valid in the minimal grammar?

No, it's the same as a no-namespace xml element name, so has to start with a letter (for some definition of letter) but may contain digits later)

[davidcarlisle]

This comment dosn't really fit under "unifying" but not sure we want a 10th open #intent issue, so adding it here...

We need somewhere to host the lists that is at least stable enough to use for the spec working drafts.

Currently we link to the original spreadsheet, and we could go with that, but the interface feels a bit wrong to me, especially as it doesn't make it so clear that people can add to level 3 but shouldn't change level 1 once it is signed off by the WG.

I exprimented after the call last night with using github pages for levels 1 and 2 and a github wiki for level 3, more comments in the readme at

https://davidcarlisle.github.io/intent/

[dginev]

Currently we link to the original spreadsheet, and we could go with that, but the interface feels a bit wrong to me, especially as it doesn't make it so clear that people can add to level 3 but shouldn't change level 1 once it is signed off by the WG.

Thanks for starting on this David! It will kick me back into gear here as well on the long-term editing side. I have been surveying the available open spreadsheet implementations and I think I'll just start a React app using ag-grid that allows editing two (directories of) JSON files - one for Intent Core and one for Intent Open, using Github's OAuth, with a git commit for each persisted edit. I'm gearing to use the named levels, since Neil keeps talking about Level 0 on even days and Level 1 on odd days, which is too confusing :-)

I think we may want to keep each "sheet" as a separate JSON file, and the really big Unicode sheet (which doesn't exist yet in the Google Sheet) may be best kept isolated. This is just a preliminary plan (welcoming feedback), since the majority of both contributing to and editing of these lists of names remains to be done. I'll let you know how this goes in the meeting next Thursday.

[davidcarlisle]

@dginev thanks. As I put in the readme, the current repo is just a discardable experiment (and may already be enough to suggest it's not really the right direction:-) So feel free to build something else... It's not super urgent as we could reference the google sheet even for a FPWG if we don't have anything else, but at some point it may start to affect the words we want to put in the spec (especially around names and number of levels and which ones are open to contributions)

[davidcarlisle]

@dginev ag-grid looks interesting

[NSoiffer]

The discussion of the format/location for the 'intent values should be in a separate issue.

The original topic has been resolved, so I'm closing this.