Correct inconsistent casing of fdc3.timeRange

kriswest commented 2 days ago

The fdc3.timeRange context type is inconsistently cased in the FDC3 docs and codebase, sometimes appearing as fdc3.timerange. This PR corrects it such that it appears as fdc3.timeRange in all cases.

Once approved the commit from this PR will need to be cherry-picked into a release/2.1.1 branch to release a corrected version of the 2.1 npm module.

netlify[bot] commented 2 days ago

Deploy Preview for fdc3 ready!

Name	Link
Latest commit	89d5ccadf3f206d43e12b84fa41a140f9b76401c
Latest deploy log	https://app.netlify.com/sites/fdc3/deploys/667ec5be3c5be2000858eb97
Deploy Preview	https://deploy-preview-1240--fdc3.netlify.app
Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

bingenito commented 2 days ago

I added a reference from the task items for fdc3-dotnet 2.1 update to also fix this.

kriswest commented 2 days ago

Seems that a majority of the implementation was all lower so I wonder if it would have made sense to stick to that in all cases, but for consistency across the API the camel casing makes more sense. I expect most usage is through the enum/constant declarations that are exported and not string literal hardcoding.

I agonized over that too - will the types have taken precedence or the examples and FDC3 workbench? In almost every cases there was a conflicting one on the same page or in the same schema. I decided to go with consistency with the rest of the standard in the end as I don't know that this type is heavily used as yet (it was originally created to support the fdc3.chart type). If we're ever going to correct it to be consistent, sooner is better.

I could add an admonition to the ref page for it, high;ighting the fact it had to be fixed...

finos / FDC3