Closed jacknely closed 10 months ago
@jacknely - related is that we follow PascalCasing for the parameters that come from HMLR, including Register Extract, OC Summary and LLC searches. I'd be fine with changing all of those too but we should do it as part of our v3.0 upgrade to minimise later disruption (we'd need to revise all our HMLR API handlers, which we're happy to do)
@jacknely - related is that we follow PascalCasing for the parameters that come from HMLR, including Register Extract, OC Summary and LLC searches. I'd be fine with changing all of those too but we should do it as part of our v3.0 upgrade to minimise later disruption (we'd need to revise all our HMLR API handlers, which we're happy to do)
@edmolyneux It feels like the right thing to do for the framework, however, I am open to aligning with the consensus of everyone currently using version 2.
If we do agree to move on this then adding to v3 release is also our preferred.
Output sample using lodash.js camelcase function:
OCSummaryData → ocSummaryData EEVoiceOutdoorNo4g → eeVoiceOutdoorNo4g cableSatelliteTV → cableSatelliteTv CCBIIndicator → ccbiIndicator HMLRReference → hmlrReference
https://github.com/Property-Data-Trust-Framework/schemas/blob/0e663399cd6800a609073b5ad0c68615b893c38c/src/schemas/v2/pdtf-transaction.json#L767
The existing PDFT implementation duplicates keys from the Ofcom payload, as indicated in the documentation: https://api.ofcom.org.uk/api-details#api=ofcom-connected-nations-api&operation=CoverageByPostCodeGet
I suggest a modification where we serialize these keys into camelCase to harmonize with the overall schema. This adjustment facilitates a consistent serialization approach for all objects within the PDFT transaction.
Considering that organizations utilizing PDTF may encounter claims from diverse sources employing keys with varying casings, adopting a uniform approach will alleviate technical challenges and enhance interoperability.