duplicated props

[VladimirAlexiev]

https://gist.github.com/VladimirAlexiev/618a9bddd6a949b75b37e983f0220417#duplicated-props

The props in these pairs are duplicated, so should be merged

• bICId: "The unique Bank Identification Code (BIC) as defined in ISO 9362 for this creditor or debtor financial institution."
  • bICIdentificationId: "The Bank Identifier Code (BIC) as defined by ISO 9362 (Banking telecommunication messages, Bank Identifier Codes) for this financial identity."
• versionId: "An identifier of the version."
  • versionIdentificationId: "The unique identifier for the version of this exchanged document."
• attachedBinaryFile: "A binary file attached to this exchanged or referenced document."
  • attachmentBinaryObject: A binary object that is attached or otherwise appended to this referenced document."
• referenceDocument
  • referencedDocument: haven't checked description

I'm sure there are more cases, how could we find them?

This is according to principle 4. deduplication of https://github.com/uncefact/vocab/pull/33 (tech-spec.md)

[onthebreeze]

Red connect in #41 - might need to manually fork & manually fix

[nissimsan]

These are excellent examples of what we inherit from the upstream model. I agree with you @onthebreeze our only option is to fork and allow ourselves to manually tidy for obvious bugs like this. The idea of doing this with NDRs or project interdependencies is completely unrealistic.

[VladimirAlexiev]

• 48, #49 will expose a lot of such cases because gratuitous naming differences will be eliminated, so we'll see the duplicates.

• referenceDocument vs referencedDocument can be caught with some simple fuzzy comparison
• attachedBinaryFile vs attachmentBinaryObject needs manual inspection

[svanteschubert]

These duplications seem to be a problem for all UN/CEFACT syntaxes. Shouldn't this be better addressed at a 'higher level' by the UN/CEFACT library maintenance team?

[nissimsan]

Yes, maybe, @svanteschubert. I labeled this semantics the other day (meaning unless we fork we won't touch it). However, if this is a consistent error which can be fixed with not-overly-complex code I wouldn't be against tagging it (also) as NDR and take it upon our internal scope to fix. (I hope it makes sense what I am expressing here :) )