4 ms·

OP here. Thanks for a lot of useful insights and references. An overall comment about a lot of the replies: A lot seem to say "you do not want to use URN becau

by dagss 4y ago

OP here. Thanks for a lot of useful insights and references. An overall comment about a lot of the replies: A lot seem to say "you do not want to use URN because X" in much the same way I think that one might criticise JSON when JSON was launched: What is the point of using JSON? Don't you realize that both systems still need to agree on a custom protocol? Yet JSON is wildly successful. I could have worded my initial request better (and the comments make me realize that, and brings my thinking forward, so thanks for that!) What I am really after is: I want to have is a standard way to refer to "an ID taken from an existing public registry", in such a way that readers realize A) they are looking at an ID in a registry B) they see which registry C) in a way that is mostly self-documentary (unlike OID!) That is only solving a single one from a ton of issues; much like two systems cannot communicate just because they both speak JSON.

CJefferson 4y ago
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!
PeterisP 4y ago
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.
Kwpolska 4y ago
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?
- dagss 4y ago
  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.
  - Kwpolska 4y ago
    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.

by dagss 4y ago

CJefferson 4y ago

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!

PeterisP 4y ago

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.

Kwpolska 4y ago

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?

dagss 4y ago
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.
- Kwpolska 4y ago
  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.