camelCasing

[VladimirAlexiev]

You use consistent camelCasing for props, and UpperCamelCasing for classes (good!). However, it needs to be made smarter when dealing with UPPERCASE:

UPPERCASE abbreviations should be converted to lowercase, then camelCased as a normal word

• otherwise:
  • casing is inconsistent depending on whether the abbreviation comes at the start or middle of the property name
  • The camelized abbreviation is impossible to recognize in the stream of words
• examples:
  • current: bBANIdentificationId, bICId, australianSNIdentificationId (wtf is BANI, ICI, SNI?)
  • change to: bbanId, bicId, australianSnId
  • or even better: bban, bic, australianSn

Haven't looked for class names. Dunno how to catch all cases.

[nissimsan]

@VladimirAlexiev, I disagree with your argument here.

australianSNIdentificationId is "The Australian Small Network (SN) identifier as assigned by the Australian Payments Clearing Association (APCA) for this creditor financial institution." (see here)

This is the input we're working from: Creditor_ Financial Institution. Australian SN_ Identification. Identifier

I won't defend why "SN" got abbreviated, but we've made a general decision not to second-guess modelling decisions. I also won't comment on IdentificationId because that's the topic of a dedicated issue. Given that, australianSNIdentificationId is the proper camelCasing.

[VladimirAlexiev]

@nissimsan don't tell me you are happy with bBANIdentificationId?

How is bBAN any better than bban?

[mgh128]

@nissimsan, @VladimirAlexiev Although it might require some second guessing that SN = serial number, I think australianSNidentificationId might be slightly better than australianSNIdentificationId because dentification itself exists as a word, meaning 'formation or conversion into a dental structure', so lower-casing the initial i in identification makes clear that it belongs together with the 'dentification' as one word 'identification' rather than being part of an abbreviation SNI, which is not the intention here.

bbanIdentificationId would make clear that the 'b' and 'ban' belong together (as an abbreviation BBAN for Basic Bank Account Number), with the case change on the capital I signalling the start of a new word, 'Identification', then again for 'Id'.

In GS1 we have a standard called EPCIS to describe traceability event data, in which many of the properties expect a list of one or more Electronic Product Codes (EPC), so we have property names such as childEPCs, epcClass, epcList, inputEPCList, outputEPCList . I suppose with hindsight it could be argued that inputEPClist and outputEPClist might have been slightly better choices but those are already in the ratified standard, so it's probably too late to rename those now.
In any case, in our properties we write EPC or epc with all three letters in the same case and don't mix the case within an abbreviation or acronym.

I hope this is helpful.

[nissimsan]

@VladimirAlexiev, that's what I'm telling you. I care less about what the result looks like, more about a simple, consistent principle: camelCase means first word lower case subsequent start letters upper case, irrespective of whether its a full word or acronymized. So, bBAN - ugly as it is, not disputing that - tells me that this is a 4-letter camel cased acronym.

@mgh128, yeah, you bundle acronym groups. That's a simple principle too. We're inheriting these terms from the upstream modelling teams, so making out an "acronym bundle" versus a word doesn't seem possible. As you know we're not supposed to make any manual adjustments. I don't think this is a possible option.

[mgh128]

Hi @nissimsan That's fine. I don't feel too strongly about it. I suppose I'm used to us taking a very pragmatic approach in the GS1 work groups in which I participate, where I (and others) don't hesitate to call out anything that looks silly or where the name or definition or data modelling is ambiguous - and to make constructive pragmatic proposals about how we think things should be done - but of course we don't have any authority to do so within your UN CEFACT work - we can only offer our own experiences (as outsiders looking in) and constructive suggestions (as we did with the Linked Data vocabulary for units of measure) and explain why we think a particular approach makes sense or has advantages over an alternative.

Some people (and even entire populations of countries) like to follow rules and process without question and without challenging them or daring to think for themselves - and as twentieth-century history has shown the world, there can be horrific outcomes when people fail to question or challenge the rules they're expected to obey. I doubt that this specific process will result in horrific outcomes (apart from a few ugly names of terms) - but if a rule or process looks defective or inadequate, I'm not afraid to point out the deficiency rather than remain silent and pretend that I'm incapable of any independent thought. I think that's a much healthier and more responsible way to work - otherwise defective rules, processes and assumptions can never be improved if nobody ever dares to challenge them.

I'm sure you'll do what you think is best - and you've now received feedback from @VladimirAlexiev and from me, which is offered with the best of intentions - and we'll continue to offer friendly and constructive help and feedback in any way we can.

[nissimsan]

Lovely, @mgh128! Much appreciated.... :)