The biggest advantage of JSON (I believe) is that it was already supported by all web browsers, so it started out as a lightweight communication method with browsers, where in the early days you didn't really want to add an alternative heavy-weight parser.

From a quick google, urn isn't built into browsers. There is a urn-parser package on npm, but it hasn't been updated in 5 years, and has exactly 0 tests. That package tells me to use the URI package, which has an open issue saying it's broken in firefox since 2011!

I have a general policy of not writing parsers wherever possible, as they are (a) really hard to get 100% right, and (b) if no-one can be bothered to keep at least one parser up to date, then it doesn't feel like a well supported language!

The usefulness of JSON is that while both systems still need to agree on a custom protocol, it gives you an implementation for half of that custom protocol - ubiquitous libraries to parse and generate the format, so the application needs only to handle the semantics of a particular field. If they made a custom format from scratch, both apps would need to reinvent the wheel and write a bunch of boilerplate code for serialization, deserialization and handling format errors.

This does not apply for URNs - the "custom protocol" replacing URNs is simply transferring a string, so choosing URNs doesn't save most apps anything.

The other aspect is that I (and looking at the other comments, probably most people) don't really identify with your use case i.e. "a standard way to refer to "an ID taken from an existing public registry"". The common use case for handling IDs from an existing registry is in systems where the requirements specify a particular existing registry, not an arbitrary one; and any URN which specifies some other registry should be rejected as invalid, so including that in the data is just useless overhead.

In general, I consider that is useful to have a reference to a specific registry if and only if I have some special integration with that registry. I.e. it's useful to denote that this is a registration number from the Danish company registry iff I do something specific with the Danish company registry (e.g. fetching whether that registration is valid and the company has not been liquidated). And in that case, I don't really need a universal format to represent arbitrary numbers, I need an 'enum' showing that this is one of the acceptable (closed!) list of number types the system can understand, or possibly even split them in separate fields in JSON/XML/whatever.

On the other hand, if try to I imagine some use cases where really there is a need for processing IDs from an open set of many registries (which exist but IMHO are quite rare) then in those cases the interpretation of these IDs is generally not done by the computer system, they are transferred and stored as-is, and perhaps later printed shown to a human. In this case, having a machine-readable URN is not an advantage, as the computer system doesn't care which registry is being used (so it doesn't need to tell that its looking at an ID in a registry, much less which registry) and potential human consumers of the data (end users like customers, accountants, etc - from whom a URN is definitely not 'self-documentary') would not be able to write or decode URNs, they would not recognize that a URN represents an ID in a registry or tell which registry is used, they would need a different, human-readable format for that.

A JSON object can solve all your problems. {"idSource": "dkCRV", "value": "12345"} or {"idSource": "plPESEL", "value": "2137"} would be quite obvious. If you’re working with a language that cares about types, you can also make idSource into an enum (so it’s harder to make a typo or implicitly forget about handling a value). And if your API offers a documentation (such as OpenAPI, or a GraphQL schema), the documentation will include a list of possible values, and tooling might even generate the nice enum for you.

Is it a standard? No. But does it need to be to be useful and obvious to everyone?

Agreed and in fact this is what is in our code even before I made the post. My main problem is that we have to invent this idSource string for all registries we support.

What does “support” entail? Whether “we print its friendly name on the invoice before its value” or “we validate it, fetch the business data from the national registries and auto-fill the rest of the form”, you still need some special handling and registration. In that case, you don’t save much by using an existing scheme, and you there is a bigger risk of someone providing a schema you don’t support.