Identifier - Serialisation Format

Noumena Protocol Language
1

Given, Identifier - Noumena Documentation

While .toText() standard library method is not supported for the values of a user-defined identifier type, logging identifier values is still possible.

What is the serialisation format, if any, for an identifier in:

  1. An engine.selectAction response?
  2. A read-model response?
  3. An argument in a notification?
2

Not sure I understand the question, 100%.

But the ApiIdentifierValue for the identifier values would be something like this:

{
  "prototypeId": "/tag?/package/Id",
  "value": "9b7e1ae9-b7c4-4922-8598-3957d1bd7d06",
  "nplType": "identifier"
}

See also Swagger definitions/OpenApi (screenshot below):

image
image977Ă—418 40.8 KB

3

The motivation for the question is whether or not a separate uuid() function in a Strings contributor library would be useful over and above the existing identifier in NPL.

One of the key issues is whether or not external applications can “see” the UUID String value of NPL identifiers.

From your answer, it looks to me like they can and so there is not as strong an argument for a separate uuid() function.

However, one other question would be can client apps rely on the underlying UUID for an NPL identifier not to change with future platform releases? If not, then I guess this is probably a deal-breaker and a uuid() function is needed after all.

4

So, my understanding is that you want to “unwrap” the value to a plain UUID.
I think, it was deliberate to keep these values “opaque”, as in the key value itself (currently a UUID) is only valid in conjunction with its type, similarly as for symbols, .e.g. chf(10) != eur(10).

As to the value itself, currently it is UUID, … and I remember vaguely discussions on “opening” this to other (customer-defined?) value types (e.g. IBAN’s and the likes… )

That said, I can’t tell if offering a uuid() in a library is reasonable (as it seems to go against this “opacity” idea…).

p.s. I’m linking @Milos and @Ari - hoping they’ll have a more qualified opinion…
and also, bring it up in the NPL council?

1 Like
5

Yes, the point with identifiers was that you can create them only via creating a new one and not by parsing a UUID. Exactly for the reason that they are tied to their types, as @Amela_Prelic mentioned. .toText() is not available as it would suggest that you can compare them e.g. on these values. There is also no .fromText. With that it mind, I am also not sure what the use case for UUIDs you have in mind. Depends on your needs.

6

My motivation is that I was asked to add a uuid() function to the Strings contributor library and I’m wondering if it’s necessary, given the identifier type.

But I believe @Krzysztof_Paprocki has a real use-case in all unity.

I think the crux of this question is really are identifiers meant to be shared outside of NPL or not?

If they’re not then I think a uuid() function is useful.
If they are then there should be a reliable way to export their representation.