Skip to content
This repository has been archived by the owner on Feb 12, 2022. It is now read-only.

Validation of example is trying to parse a date value as XML or JSON #665

Closed
juanchib opened this issue Oct 8, 2019 · 4 comments
Closed
Milestone

Comments

@juanchib
Copy link
Contributor

juanchib commented Oct 8, 2019

#%RAML 1.0
title: test 

/test:
  get:
   queryParameters:
     timeout:
       type: date-only
       required: true
       example: <2019-09-09>

Validation of the example is throwing - Error validating XML. Error: The markup in the document preceding the root element must be well-formed. [line=11, col=17] when the expected error message is Provided value <2019-09-09> is not compliant with the format date_only provided in rfc3339
Same happen when the example value starts with { the example is treated as JSON.

jpbelang added a commit that referenced this issue Oct 20, 2019
It now checks to see if it parses, otherwise, it treats as a string....
@jpbelang
Copy link
Collaborator

The way I can do this is attempt to actually parse the example as either XML or JSON and upon failing that, not treat it as a XML or JSON document.

This makes invalid JSON examples error messages more obscure:

/hello:
  get:
  post:
    responses:
      202:
        body:
          application/json:
            type: object
            properties:
              key:
                type: object
                properties:
                  x: string
                example: |
                  {
                  x: "lala"
                  }

used to say: "Error validating JSON. Error: Unexpected character ('x' (code 120)): was expecting double-quote to start field name"
But now says: "Invalid type String, expected Object for example", as it will now not be parsed as json, it will be treated as a string.

Honestly, I don't think it's worth the change. I'll try to find a better solution, but there's not many variations.

jpbelang added a commit that referenced this issue Oct 20, 2019
It now checks to see if it parses, otherwise, it treats as a string....
jpbelang added a commit that referenced this issue Oct 20, 2019
It now checks to see if it parses, otherwise, it treats as a string....
@jstoiko jstoiko added this to the 1.0.44 milestone Oct 28, 2019
@jstoiko
Copy link
Contributor

jstoiko commented Oct 29, 2019

On a semi-related note: be aware that in RAML, examples do not have to be defined in the same syntax as the media type(s) of the parent resource.

There are two reasons for this:

  1. Content negotiation: some APIs and their underlying resources may support content type negotiation which means that a given payload in the API definition may be defined in YAML or JSON but the actual payload that people would end-up seeing/getting over the network could be in a different media type. One way to achieve this could be to use the RAML default media type feature.
  2. Also, what an API definition primarily describes is the semantic, not the syntax (although it can enforce a particular syntax). Examples in RAML are defining the semantic (it's an object, it has properties, those properties may have certain values) and that can be represented in any supported format.

@jstoiko jstoiko modified the milestones: 1.0.44, 1.0.45 Oct 31, 2019
@jstoiko
Copy link
Contributor

jstoiko commented Nov 6, 2019

The issue comes from the fact that there is "pre-processing" validation happening when an example defined on ANY type starts with either < (XML), or {, [ (JSON). That validation should only happen when the type or one of the subtypes (union) is object.

@juanchib: make sense?

@juanchib
Copy link
Contributor Author

juanchib commented Nov 7, 2019

@jstoiko yes it makes total sense to me. Thanks

jpbelang added a commit that referenced this issue Nov 14, 2019
* Best attempt at fixing #665

It now checks to see if it parses, otherwise, it treats as a string....

* Best attempt at fixing #665

It now checks to see if it parses, otherwise, it treats as a string....

* Best attempt at fixing #665

It now checks to see if it parses, otherwise, it treats as a string....

* Better first part of a solution.

* This works, I think.

* Simpler approach.
juanchib pushed a commit to juanchib/raml-java-parser that referenced this issue Mar 4, 2020
* Best attempt at fixing raml-org#665

It now checks to see if it parses, otherwise, it treats as a string....

* Best attempt at fixing raml-org#665

It now checks to see if it parses, otherwise, it treats as a string....

* Best attempt at fixing raml-org#665

It now checks to see if it parses, otherwise, it treats as a string....

* Better first part of a solution.

* This works, I think.

* Simpler approach.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants