Code assist for `format` keyword inserts empty quotes about kaizen-openapi-editor HOT 14 CLOSED

Just verified it on the latest build - it's still there.

from kaizen-openapi-editor.

The problem is that the json-schema for swagger does not provide any values for this property. See https://github.com/ModelSolv/SwagEdit/blob/master/com.reprezen.swagedit/src/com/reprezen/swagedit/json/schema.json#L932

from kaizen-openapi-editor.

I'd recommend fixing this (and a few other issues) by amending the schema to add an appropriate enum restriction in each case.

In this particular case, I think we could submit our schema change as a pull request back to the swagger-spec project. But regardless of whether our PR is accepted, it makes sense for SwagEdit to own and control its own version of the schema.

(Note: In other cases, we'd maintain our changes locally because they aren't strictly required. For example, the spec doesn't require schemes to be specified; it defaults to a value of http; but the Swagger UI doesn't recognize this default, and therefore requires schemes to be explicitly specified. We might want to require it in API Studio for this reason, and a schema change might be the most expedient way to do that.)

from kaizen-openapi-editor.

I took the formats from here http://swagger.io/specification/#dataTypeFormat, and implemented like below in schema.json file. I left the default string type, so that users can still define their own formats.

 "format": {
    "oneOf": [
      {
        "type": "string"
      },
      {
        "type": "string",
        "enum": [
          "int32",
          "int64",
          "float",
          "double",
          "byte",
          "binary",
          "date",
          "date-time",
          "password"
        ]
      }
    ]
  }

Completion for format

from kaizen-openapi-editor.

@ghillairet , good idea. I didn't realize that Swagger allowed custom formats.

But IIUC, JSON Schema's oneOf will fail validation if a value matches more than one of the provided schemas. Would anyOf work better here?

from kaizen-openapi-editor.

JSON Schema oneOf doc:

http://json-schema.org/latest/json-schema-validation.html#anchor88

from kaizen-openapi-editor.

Not sure about this.

oneOf > validates successfully against exactly one schema
anyOf > validates successfully against at least one schema

I would say oneOf is ok.

from kaizen-openapi-editor.

Please try it with a JSON schema validator. I think the difference between oneOf and anyOf is as I described. oneOf has to match exactly one of the provided schemas. It's an XOR, whereas anyOf is an inclusive OR.

from kaizen-openapi-editor.

Both cases don't make any difference for the validator, since the first schema matches all string and the second matches a enum of strings. It's always the first schema that will be taken into account for validation. If it's not a string, then validation will fail.

So I believe for this case anyOf or oneOf are both valid.

from kaizen-openapi-editor.

Reopening, as I see a few problems remaining:

1. The definition is repeated several times in the schema. It should be specified once, in the definitions section, and referenced there. In this milestone, even if we don't address any of the other points below, we should at least address that one.
2. There are no unit tests to validate that the code assist suggestions are working correctly.
3. I checked the JSON Schema Test Suite and tested in JSON-Schema Lint. It's clear that anyOf is the correct validation to use here.

Using the schema as specified, with oneOf:

{
  "oneOf": [
    {
      "type": "string"
    },
    {
      "type": "string",
      "enum": [
        "int32",
        "int64",
        "float",
        "double",
        "byte",
        "binary",
        "date",
        "date-time",
        "password"
      ]
    }
  ]
}

Here's JSON Schema Lint on a non-string value, as a baseline test:

Here's a random string, which matches the first schema, but not the second, and therefore satisfies oneOf:

Here's "double", which matches both schemas, and therefore fails oneOf

Change the first schema to number, and it passes validation:

Or change it back to string but use anyOf instead of oneOf. Again, it passes:

So I have to conclude that the JSON Schema validator we're using in SwagEdit / YEdit is not implementing oneOf semantics correctly. This is not caused any other problems that we've noticed so far, but it's something to be aware of. And we don't want our schema to start reporting validation errors if we upgrade to a new validator that fixes this problem.

from kaizen-openapi-editor.

I changed to use anyOf instead.

Note for later that validation fails also here with oneOf http://json-schema-validator.herokuapp.com/
This online validator uses the validation library we are using in SwagEdit, so there is maybe a bug in the library.

from kaizen-openapi-editor.

@ghillairet , this change looks good. Please open a PR for this.

from kaizen-openapi-editor.

6c1a1d9 was committed directly to master.

from kaizen-openapi-editor.

There is still no unit tests for this functionality, created #84 "Tests for code assist for format".
Closing this issue.

from kaizen-openapi-editor.