Rules around the “incode” bit of the org ID

[andylolz]

I have a question related to this comment.

Am I correct in thinking "BE-BCE_KBO-0421210424", and "BE-BCE_KBO-0421210424 " (i.e. with a space on the end) are two separate and equally valid org IDs?

Or rather: that it’s down to the business rules of the BE-BCE_KBO list to decide otherwise?

Relatedly: Does org-id.guide impose any rules about what constitutes a valid / invalid agency code? If not, (and this is the main question, really) should the related IATI standard ruleset rule be relaxed/removed?

[BobHarper1]

I would ask, why the space? If the space isn't part of the identifier that the registration agency (BCE) gives out, so I wouldn't expect to see it form part of a valid code (otherwise, what's to stop any number of whitespaces being used?)

There is no true consistency around formatting of agency codes. It is usually the "how to locate and use identifiers" section that gives the guidance around what to do. But in most cases if there is whitespace within the agency code itself I'm assuming that the guidance would be to remove these (see also).

I've found that agency website might use the codes in two different ways themselves in their own interfaces (e.g. with or without non-alphanumeric characters), so the guidance part is important as to removing ambiguity - but not always consistent from one list to the other.

So we could actually say that "BE-BCE_KBO-0421.210.424" (as it is on the search site) is actually the valid org-id because BE-BCE_KBO doesn't say to remove dots.

[andylolz]

There is no true consistency around formatting of agency codes. It is usually the "how to locate and use identifiers" section that gives the guidance around what to do

Exactly – that’s what I meant by “it’s down to the business rules of the BE-BCE_KBO list to decide otherwise”. Okay, cool!

I'm assuming that the guidance would be to remove these

Well, the guidance doesn’t say anything about whitespace… So it would be wrong to assume this, wouldn’t it? This is the crux of my question, really – i.e. is there any stuff that org-id.guide assumes, that isn’t part of the registration agency’s own rules? Perhaps in this case whitespace isn’t important, but for other lists it might be – so I’d guess it’s probably best not to assume.

The origin of my question is: IATI has some fairly arbitrary rules about org IDs (forward slashes, ampersands, pipes and question marks are not allowed), and I wonder if these should cease to exist now that the org-id.guide approach is to be followed. This is particularly relevant, because the IATI registry maintainers are talking about introducing validation on newly created org IDs. They could check for question marks, pipes and backslashes, but I think they probably shouldn’t (I think they’d be better off checking prefixes against the org-id.guide register).

[BobHarper1]

Well, the guidance doesn’t say anything about whitespace… So it would be wrong to assume this, wouldn’t it?

Yes, but it there's no whitespace in the original agency code in this example, why would it be introduced? (and how would we detail its removal if there were none to remove?) But, in any case, what I'm saying is in most cases the business rules would say to remove whitespace... I assume!

The origin of my question is: IATI has some fairly arbitrary rules about org IDs (forward slashes, ampersands, pipes and question marks are not allowed), and I wonder if these should cease to exist now that the org-id.guide approach is to be followed

I would agree, in principle. The IATI Standard could, in theory, apply its own rules and ignore those on the site to support its own use case, but that would seem to be at cross purposes.

[andylolz]

in most cases the business rules would say to remove whitespace

I think we’re agreeing here. I’m asking about the rules org-id.guide introduces – not the rules of the registration agency. I think you’re saying: there aren’t any. I.e. the only rules are those of the registration agency. If whitespace is not allowed, that’s the registration agency’s call (and NOT org-id.guide.)

That said… Looking at UG-RSB, for instance… It looks like spaces in the examples have been stripped out (source). So perhaps this is a rule of org-id.guide after all?

On the second part of the question, consider ZW-PVO-42/10. This is a totally valid org ID according to the guidelines on org-id.guide (indeed, it’s one of the examples provided). However, it’s invalid according to current IATI rules, because it includes forward slashes. That’s problematic if IATI is following the org-id.guide methodology.

[andylolz]

The whitespace stripping in this example is crazy bananas:

PT-NIPPC-9digits;thelastdigitisthecheckdigit.Thefirstdigitdependsonwhatthenumberrefersto(5arecompanies.)

I mean, this really looks like either a bug on the frontend, or an (unwritten) org-id.guide rule.

[BobHarper1]

Whoa, thanks. Looks like a how to find... value ended up in the example property by mistake

[andylolz]

Yeah there are a few broken examples (e.g. GG-RCE; the first example on FR-RCS) but my point is: whitespace is being stripped from all examples that contain it.

[andylolz]

We basically didn’t get to the bottom of this.