The data model uses "name" for both namespaced and non-namespaced names

[eemeli]

We currently have

message-format-wg/spec/data-model/README.md

Lines 168 to 171 in 2a69d2a

	interface VariableRef {
	type: "variable";
	name: string;
	}

but also

message-format-wg/spec/data-model/README.md

Lines 183 to 193 in 2a69d2a

	interface FunctionAnnotation {
	type: "function";
	kind: "open" | "close" | "value";
	name: string;
	options?: Option[];
	}
	interface Option {
	name: string;
	value: Literal | VariableRef;
	}

In the former, the "name" is a non-namespaced name, while in the latter it's an identifier, which may also include a namespace.

Which of the following should we do?

1. Change the function & option "names" to be called something else.
2. Add the namespace to the data model as a separate field.
3. Note in the text that these have different contents.
4. Something else?

This issue was originally raised by @aphillips in #574 (comment), as markup will also be affected.

[aphillips]

I think the core question here is: is namespace a separate item in the data model?

If it is, it's a separate optional field and name represents the non-optional name of a function, variable, markup, or other entity. This seems like what we intend?

If it isn't that implies that x:foo is distinct from foo and the fields that take identifier in the ABNF have identifier fields in the data model.

[aphillips]

#543 was roughly the same as this issue. It said:

---

In #524 (review), @stasm asked:

Do we want namespaces to be a separate concept in the data model? Or should the data model just store the stringified identifier, i.e. ns:name?

@eemeli replied:

I would prefer not adding namespaces to the data model, and continuing there with a single-string name.

This issue is to discuss whether we should separate namespace in the data model or not.

[catamorphism]

Option (2) seems desirable, since an external tool processing a data model should treat function x:foo as foo if it doesn't have a registry that defines things in namespace x.

Without adding the namespace as a separate field, such a tool would have to do additional parsing on the name field in the FunctionAnnotation, which doesn't seem ideal (likewise for option names), since the data model is supposed to be an already-parsed representation.

[eemeli]

Option (2) seems desirable, since an external tool processing a data model should treat function x:foo as foo if it doesn't have a registry that defines things in namespace x.

Where do we say this?

[catamorphism]

Where do we say this?

I guess we don't. I must have been thinking of an old discussion.

However, I still have the same preference, but for a different reason.

If the implementation cannot find the function, or if the identifier includes a namespace that the implementation does not support, emit an Unknown Function error and use a fallback value for the expression.

-- step 2 of "Function Resolution" in the spec

If the namespace isn't a separate field in the data model, then the implementation either has to parse the function name every time, or use its own internal data model that does have a separate "namespace" field.

In general, a data model is a parsed representation of the syntax. Since the grammar includes:

identifier = [namespace ":"] name

parsing includes splitting an identifier into a namespace component and a name component.

[aphillips]

In the 2024-02-15 F2F call, we decided to keep the word "name" in data model, but add text that says something like "sometimes, names can be identifiers"