Property-Data-Trust-Framework / schemas

Open data schema for digital residential property data exchange
MIT License
13 stars 11 forks source link

Connectivity: Keys do not follow same casing as rest of schema #133

Closed jacknely closed 10 months ago

jacknely commented 11 months ago

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.

edmolyneux commented 11 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 commented 11 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)

@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.

jacknely commented 11 months ago

Output sample using lodash.js camelcase function:

OCSummaryData → ocSummaryData EEVoiceOutdoorNo4g → eeVoiceOutdoorNo4g cableSatelliteTV → cableSatelliteTv CCBIIndicator → ccbiIndicator HMLRReference → hmlrReference