Change provider_state to providerState about pact-specification

[davesmith00000]

Just to tag on a note from the google group where we've just had the same discussion :-)

Another way to go might be a linter / validator for implementation developers to use to ensure they'e conforming to agreed standards. I would have thought this would be fairly straight forward to set up given that we must read and validate Pact files already? The catch might be having the ability to specify which Pact version to validate against and providing version specific errors...

Just a thought.

[BenSayers]

I'm writing some code that parses pact files, I can't see anywhere in the specification tests where provider state is defined. Should it be providerState or provider_state? And has this changed between pact specification versions?

[uglyog]

The original Ruby version used provider_state, but that was changed very early on because JSON in general uses camel case. But more to your point, there is no formal example or schema in the specification project for a Pact file.

[BenSayers]

If you would accept a JSON Schema file for Pact I'd be happy to contribute it. I'd just need some guidance on where it should live and how we can test it's correctness. Maybe each of the pact fragments in this specification project could be validated by the schema?

[uglyog]

More than happy to accept a Schema file. You can create it in the root of the project for the appropriate branch, and we need to also create an example test pact file for it. The test cases are not full pact files, so we can't use those.

[uglyog]

@davesmith00000 That is a good idea, it won't be hard to take the existing Pact reading code out of one of the implementations and create a verifier tool.

[mefellows]

The Rust work you've done @uglyog seems like a good candidate :)

[BenSayers]

I've made a start on creating the JSON Schemas and have a close to complete schema for Pact v1.0.0. I put it in a seperate project as I wanted to write automated tests to verify the schema is correct, but if you want to move it somewhere else I don't mind.

https://bitbucket.org/atlassian/pact-json-schema/overview
https://www.npmjs.com/package/pact-json-schema

Who is the best person to work with to check my assumptions?

[BenSayers]

I created a list of assumptions/questions I have here:

https://bitbucket.org/atlassian/pact-json-schema/issues/4/get-pact-community-to-validate-v1-schema

[mefellows]

I get an Error "Access Denied" page trying to get to that issue, but I can browse the source.

In any case @uglyog and @bethesque are probably the best people to review this.

[BenSayers]

Sorry @mefellows I screwed up the permissions. Should be fixed now.

[BenSayers]

@uglyog @bethesque feel free to throw inline comments here, which you should have permission to do after logging in:

https://bitbucket.org/atlassian/pact-json-schema/commits/a07b4776913aec3d1eb146f78c14e72361aee4ec?at=master#chg-schemas/v1.0.0/schema.json

[bethesque]

In https://bitbucket.org/atlassian/pact-json-schema/src/529795b6fc02df10b7a24f4390aa9fb9476473e8/schemas/v1/schema.json?at=master&fileviewer=file-view-default there is no mention of providerState. Only the very earliest pacts (mostly in REA) used provider_state, so I think it should be providerState.

[bethesque]

What about consumer name and provider name?

[bethesque]

Just a semantic issue, I'd say "There is one schema for each Pact specification version", because we don't want to confuse it with the concept of "pact instance versions".