URN Implementation

[juztas]

This is based on John's URN doc. Need to review it and solve conflicts

[gabor-lbl]

Why all this complexity? How about just new enum(str)-s of the urls?

[juztas]

Which part? Regex? I don't think there is an easier way to achieve the correct result without enforcing the validation contract. It could easily accept everything, but we will end up drifting from an RFC and diff naming: compute vs Compute. Enums will not work if we want to allow facilities to define their own names, like urn:doe-iri:something:fancy. I see this where we want to put trust in the output? On Facilities, to always know what to define and trust them, or enforce it at this level and validate what facility sets?

[gabor-lbl]

Yes, I meant all the validation logic. What if we only allow facilities under a prefix like urn:doe-iri:facility:...?

[juztas]

Validation needs to stay, based on John's RFC (see section 2: https://github.com/doe-iri/iri-facility-api-docs/blob/main/rfc/rfc-iri-urn-structure-and-registry.md). I prefer to break it early on code, rather than identifying it later as a mistake in length, _-, etc.
Enums will not work, as it would limit our capabilities (and always require defining it)
For urn:doe-iri:facility:... see section 4, the facility code can be at any level

urn:doe-iri:<facility-code>:pdu:breaker
urn:doe-iri:resource:<facility-code>:dpu
urn:doe-iri:resource:compute:<facility-code>:fpga

So validation accepts it all, and the main thing is that it validates syntax and rejects malformed inputs. If you see an easier way, would you be able to take the code base and propose an easier solution?

[gabor-lbl]

Ok, I'm good then - thanks for the explanation.

[pmrich]

LGTM. Gabor's questions have been addressed.