Thread: Open vs closed indicator registry

We began with a handful of indicators and have now expanded to 25. Each addition has been drawn from the classical sources. But is this the complete set, or should the specification permit communities to define their own?

My grandfather's community in Baghdad used the evening call to prayer from the nearby mosque as an indicator for nightfall. This is not in the Talmud, but it was reliable and locally meaningful. Should such an indicator be expressible in our system?

Why would we want to permit this? The specification becomes useless if every community invents its own codes. +MQ might mean "mosque call" in Baghdad and "market quiet" in Vilna.

My grandfather's community in Baghdad used the evening call to prayer

My grandfather would have understood this immediately. In Munkács, the church bells served a similar function. Not because they were religiously meaningful, but because they were audible. You did not need to see the sky.

The question is whether such local knowledge belongs in a specification that must work everywhere.

The question is whether such local knowledge belongs in a specification

But is this not what the Talmud itself does? It records multiple indicators precisely because different communities observed different things. Dogs bark everywhere, but not every community has ravens. The sages did not restrict themselves to a fixed list.

Perhaps we should follow their example. The specification could define a core set of indicators—those attested in the classical sources—while permitting extensions for local use.

How would a reader know what an extension means?

Local indicators work because communities share knowledge. Can a specification carry that knowledge?

The specification cannot carry that knowledge.

Then perhaps the specification should reference external sources of knowledge. A community could publish its indicator definitions somewhere—a document, a registry—and strings could reference that source.

Couldn't we use a prefix system? Local indicators could be namespaced. MUNKACS:BK for Munkács bakery, BAGHDAD:MQ for the mosque call. The prefix identifies the source; the code identifies the indicator within that source.

Who maintains the namespace registry?

Suppose I receive a string with an indicator I do not recognize. What do I do?

If the indicator is from the core set and I do not recognize it, my implementation is broken. But if it is a local extension, non-recognition is expected. How do I distinguish these cases?

How do I distinguish these cases?

The prefix would indicate it. Core indicators have no prefix. Extended indicators have a community prefix. If you see +S3, it is from the core set. If you see +MUNKACS:BK, it is a local extension.

There are established patterns for this. The way language tags work, or media types, or—

Actually, could we not simply use a standard prefix system? There must be conventions for this sort of thing. Some way to indicate "this identifier belongs to that authority." If only there were a way to include local indicators without requiring central coordination. Some kind of distributed system where each community could publish its own definitions, and the prefix would tell you where to look...

You are describing the current state of halakha.

If only there were a way to include local indicators without requiring central coordination.

R. Nachmani raises an interesting architectural question. But before we solve it, should we not ask whether it needs solving?

The indicators we have defined are those attested in classical sources. Why have they survived? Because they encode observations that remain valid across centuries and geographies. Stars are visible everywhere. Markets close everywhere. Dogs bark everywhere.

Local indicators—the bakery, the mosque, the church bells—are valuable precisely because they are local. Do they generalize? Would a specification that encoded them not need to encode the entire context in which they are meaningful?

A specification that encoded them would need to encode the entire context

But we already have context tokens. Could a local indicator not simply require an accompanying context? +BAGHDAD:MQ@BAGHDAD would mean "mosque call, meaningful in Baghdad context."

Is this not getting complicated? We now need: a namespace registry, a prefix syntax, context tokens, and the assumption that anyone reading the string has access to the community's indicator definitions.

For what benefit? So that someone in Baghdad can encode that the mosque has called? Could they not simply use +CL—customary lighting threshold reached? Does the specification not already have a code for "the local community says it is time"?

Dr. Stern makes an important point. The CL indicator exists precisely for this case. It encodes "the community has determined, by whatever local means, that a threshold has been reached." It does not require specifying which threshold or how it was determined.

Perhaps the question is not whether we should permit extensions, but whether the existing indicators already cover the cases that matter.

whether the existing indicators already cover the cases that matter

Who decides what matters?

The Kotzker is supposed to have said: "A committee that tries to include everyone will satisfy no one. A committee that satisfies itself will accidentally include everyone who matters."

I am not sure he actually said this. But if he did not, he should have.

Perhaps we are asking the wrong question. We keep asking "should the registry be open or closed?" But is a closed registry a claim about the world, or a claim about the specification?

If we close the registry, are we saying "these are the only valid indicators"? Or are we saying "these are the only indicators this specification addresses"?

Is there a difference?

Of course there is a difference. One is a limitation, the other is a prohibition.

To whom? To the community that uses an indicator the specification does not recognize? To the implementer who must decide what to do with it? To the reader who cannot parse the string?

To the implementer, surely. If I receive an unrecognized indicator and the registry is closed, I reject the string. If the registry is open, I... what? Accept it? Ignore it? Pass it through?

This is exactly the question. What does an implementation do with an indicator it does not recognize?