RAML API defining issues

Hello everybody!

Recently, I was trying to update our raml files by adding response body schemas. This seem to have been already mentioned before on this group, but I guess no one found the way to solve it (https://groups.google.com/forum/#!topic/openlmis-dev/_7GciBqHLfU). There seems to be a problem with defining “arrays of objects of specified type”. We define a schema like this:

- facilityArray: |
 {
 "type": "array",
 "items": { "type": "object", "$ref":"#/schemas/facility" }

 }

Then, if we put this as a schema for response body, the integration test would fail on following line:

assertThat(RAML_ASSERT_MESSAGE, restAssured.getLastReport(), RamlMatchers.hasNoViolations());

saying, that “the reference schema could not be resolved” (more info in the topic linked above).

I have not found any solution or live example in official raml docs, though I found a post on their official forum with similar issue (http://forums.raml.org/t/set-body-to-be-array-of-defined-schema-objects/1566).

From what is suggests, RAML 0.8 does not fully support that kind of declaration, or at least it’s related tools do not.

Does anyone know a solution to this issue?

If we can’t come up with a solution to this, we may switch to RAML 1.0 (although we might also need to revise if our tools support it), or have some workaround (like defining the above facilityArray as array of objects without referencing schema (so we’re losing consistency), or copy-paste facility’s definition in place of reference (making redundant declaration) - those two are proven to work).

Best regards,

Paweł

Hey Paweł,

From doing some research, it appears that it would be ideal to go to RAML 1.0, since it introduces the idea of something called “data types,” which appears to do what we want in defining JSON schemas. Then we could define our schemas in the more readable RAML format instead of using JSON Schema format. However, our RAML testing tool does not have support for RAML 1.0 yet, and it’s not clear when that support will be implemented.

One way we could do it is try to (via a script or tool) replace all JSON objects that contain the $ref property and expand them to their JSON Schema definitions. This seems like it might take some work. I don’t think I would recommend trying it this way.

Another way we could do it is to define our JSON Schemas in external JSON files and then reference them in the RAML like so:

  • facility: !include schemas/facility.json

  • facilityArray: |

    {

      "type": "array",
    
      "items": { "type": "object", "$ref": "schemas/facility.json" }
    

    }

That would create a number of extra files, but I haven’t determined a way to reference JSON Schemas in RAML.

Shalom,

Chongsun

– ​

There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongsun.ahn@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

···

On Oct 10, 2016, at 5:53 PM, Paweł Nawrocki pnawrocki@soldevelo.com wrote:

Hello everybody!

Recently, I was trying to update our raml files by adding response body schemas. This seem to have been already mentioned before on this group, but I guess no one found the way to solve it (https://groups.google.com/forum/#!topic/openlmis-dev/_7GciBqHLfU ). There seems to be a problem with defining “arrays of objects of specified type”. We define a schema like this:

- facilityArray: |
 {
 "type": "array",
 "items": { "type": "object", "$ref":"#/schemas/facility" }

 }
Then, if we put this as a schema for response body, the integration test would fail on following line:


assertThat(RAML_ASSERT_MESSAGE, restAssured.getLastReport(), RamlMatchers.hasNoViolations());

saying, that "the reference schema could not be resolved" (more info in the topic linked above).


I have not found any solution or live example in official raml docs, though I found a post on their official forum with similar issue ([http://forums.raml.org/t/set-body-to-be-array-of-defined-schema-objects/1566](http://forums.raml.org/t/set-body-to-be-array-of-defined-schema-objects/1566)).
From what is suggests, RAML 0.8 does not fully support that kind of declaration, or at least it's related tools do not.


Does anyone know a solution to this issue?


If we can't come up with a solution to this, we may switch to RAML 1.0 (although we might also need to revise if our tools support it), or have some workaround (like defining the above facilityArray as array of objects without referencing schema (so we're losing consistency), or copy-paste facility's definition in place of reference (making redundant declaration) - those two are proven to work).


Best regards,
Paweł

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/b42f68cc-9798-4568-b049-172c0b8ba858%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

Hey!

It seems that we keep referencing schemas the wrong way, and it works only because we don’t validate raml in those controller tests.

Schemas are still being references directly, instead of switching to the style you suggested.

I’m curious if we’re leaving this for now as it is, or should we should start enforcing the proper style somehow?

Cheers,

Paweł

W dniu środa, 12 października 2016 14:39:56 UTC+2 użytkownik chongsun.ahn napisał:

···

Hey Paweł,

From doing some research, it appears that it would be ideal to go to RAML 1.0, since it introduces the idea of something called “data types,” which appears to do what we want in defining JSON schemas. Then we could define our schemas in the more readable RAML format instead of using JSON Schema format. However, our RAML testing tool does not have support for RAML 1.0 yet, and it’s not clear when that support will be implemented.

One way we could do it is try to (via a script or tool) replace all JSON objects that contain the $ref property and expand them to their JSON Schema definitions. This seems like it might take some work. I don’t think I would recommend trying it this way.

Another way we could do it is to define our JSON Schemas in external JSON files and then reference them in the RAML like so:

  • facility: !include schemas/facility.json
  • facilityArray: |
  {
      "type": "array",
      "items": { "type": "object", "$ref": "schemas/facility.json" }
  }

That would create a number of extra files, but I haven’t determined a way to reference JSON Schemas in RAML.

Shalom,

Chongsun

– ​

There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongs...@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

On Oct 10, 2016, at 5:53 PM, Paweł Nawrocki pnaw...@soldevelo.com wrote:

Hello everybody!

Recently, I was trying to update our raml files by adding response body schemas. This seem to have been already mentioned before on this group, but I guess no one found the way to solve it (https://groups.google.com/forum/#!topic/openlmis-dev/_7GciBqHLfU ). There seems to be a problem with defining “arrays of objects of specified type”. We define a schema like this:

- facilityArray: |
 {
 "type": "array",
 "items": { "type": "object", "$ref":"#/schemas/facility" }

 }
Then, if we put this as a schema for response body, the integration test would fail on following line:


assertThat(RAML_ASSERT_MESSAGE, restAssured.getLastReport(), RamlMatchers.hasNoViolations());

saying, that "the reference schema could not be resolved" (more info in the topic linked above).


I have not found any solution or live example in official raml docs, though I found a post on their official forum with similar issue ([http://forums.raml.org/t/set-body-to-be-array-of-defined-schema-objects/1566](http://forums.raml.org/t/set-body-to-be-array-of-defined-schema-objects/1566)).
From what is suggests, RAML 0.8 does not fully support that kind of declaration, or at least it's related tools do not.


Does anyone know a solution to this issue?


If we can't come up with a solution to this, we may switch to RAML 1.0 (although we might also need to revise if our tools support it), or have some workaround (like defining the above facilityArray as array of objects without referencing schema (so we're losing consistency), or copy-paste facility's definition in place of reference (making redundant declaration) - those two are proven to work).


Best regards,
Paweł

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to
openl...@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/b42f68cc-9798-4568-b049-172c0b8ba858%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

Hey Paweł,

Yes, we should be switching over to the style I’ve suggested. As for how we will be refactoring the current source code, our team here is working on a ticket to give guidance on how to document this new way in the RAML when working on a ticket. Instead of having one person try to refactor the entire RAML to the new way, we’ll probably be refactoring parts of it over time, as we work on different parts of the code. I welcome any feedback you have for this process.

Shalom,

Chongsun

– ​

There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongsun.ahn@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

···

On Oct 24, 2016, at 10:43 AM, Paweł Nawrocki pnawrocki@soldevelo.com wrote:

Hey!

It seems that we keep referencing schemas the wrong way, and it works only because we don’t validate raml in those controller tests.

Schemas are still being references directly, instead of switching to the style you suggested.

I’m curious if we’re leaving this for now as it is, or should we should start enforcing the proper style somehow?

Cheers,

Paweł

W dniu środa, 12 października 2016 14:39:56 UTC+2 użytkownik chongsun.ahn napisał:

Hey Paweł,

From doing some research, it appears that it would be ideal to go to RAML 1.0, since it introduces the idea of something called “data types,” which appears to do what we want in defining JSON schemas. Then we could define our schemas in the more readable RAML format instead of using JSON Schema format. However, our RAML testing tool does not have support for RAML 1.0 yet, and it’s not clear when that support will be implemented.

One way we could do it is try to (via a script or tool) replace all JSON objects that contain the $ref property and expand them to their JSON Schema definitions. This seems like it might take some work. I don’t think I would recommend trying it this way.

Another way we could do it is to define our JSON Schemas in external JSON files and then reference them in the RAML like so:

  • facility: !include schemas/facility.json
  • facilityArray: |
  {
      "type": "array",
      "items": { "type": "object", "$ref": "schemas/facility.json" }
  }

That would create a number of extra files, but I haven’t determined a way to reference JSON Schemas in RAML.

Shalom,

Chongsun

– ​

There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongs…@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

On Oct 10, 2016, at 5:53 PM, Paweł Nawrocki <pnaw…@soldevelo.com> wrote:

Hello everybody!

Recently, I was trying to update our raml files by adding response body schemas. This seem to have been already mentioned before on this group, but I guess no one found the way to solve it (https://groups.google.com/forum/#!topic/openlmis-dev/_7GciBqHLfU ). There seems to be a problem with defining “arrays of objects of specified type”. We define a schema like this:

- facilityArray: |
 {
 "type": "array",
 "items": { "type": "object", "$ref":"#/schemas/facility" }

 }
Then, if we put this as a schema for response body, the integration test would fail on following line:


assertThat(RAML_ASSERT_MESSAGE, restAssured.getLastReport(), RamlMatchers.hasNoViolations());

saying, that "the reference schema could not be resolved" (more info in the topic linked above).


I have not found any solution or live example in official raml docs, though I found a post on their official forum with similar issue ([http://forums.raml.org/t/set-body-to-be-array-of-defined-schema-objects/1566](http://forums.raml.org/t/set-body-to-be-array-of-defined-schema-objects/1566)).
From what is suggests, RAML 0.8 does not fully support that kind of declaration, or at least it's related tools do not.


Does anyone know a solution to this issue?


If we can't come up with a solution to this, we may switch to RAML 1.0 (although we might also need to revise if our tools support it), or have some workaround (like defining the above facilityArray as array of objects without referencing schema (so we're losing consistency), or copy-paste facility's definition in place of reference (making redundant declaration) - those two are proven to work).


Best regards,
Paweł

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev…@googlegroups.com.

To post to this group, send email to openl…@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/b42f68cc-9798-4568-b049-172c0b8ba858%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/bb751145-ae30-4fc1-af80-6374a43c91ad%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Hey everyone,

I have been working on establishing the new pattern of JSON schemas for our RAML (OLMIS-894) for OpenLMIS v3 and have checked in some changes to the RAML in the Reference Data Service. You can see an example of how JSON schema is defined in the RAML (for a right and a rightArray, a list of rights) at the following link:

https://github.com/OpenLMIS/openlmis-referencedata/blob/master/src/main/resources/api-definition.yaml#L254

The actual JSON schema definition for a right is in a separate file at this link:

https://github.com/OpenLMIS/openlmis-referencedata/blob/master/src/main/resources/schemas/right.json

As we make changes to the API definition in the RAML for v3, we should try to follow this pattern in defining JSON schemas. Please let me know if you have any feedback.

Shalom,

Chongsun

– ​

There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongsun.ahn@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

···

On Oct 24, 2016, at 10:43 AM, Paweł Nawrocki pnawrocki@soldevelo.com wrote:

Hey!

It seems that we keep referencing schemas the wrong way, and it works only because we don’t validate raml in those controller tests.

Schemas are still being references directly, instead of switching to the style you suggested.

I’m curious if we’re leaving this for now as it is, or should we should start enforcing the proper style somehow?

Cheers,

Paweł

W dniu środa, 12 października 2016 14:39:56 UTC+2 użytkownik chongsun.ahn napisał:

Hey Paweł,

From doing some research, it appears that it would be ideal to go to RAML 1.0, since it introduces the idea of something called “data types,” which appears to do what we want in defining JSON schemas. Then we could define our schemas in the more readable RAML format instead of using JSON Schema format. However, our RAML testing tool does not have support for RAML 1.0 yet, and it’s not clear when that support will be implemented.

One way we could do it is try to (via a script or tool) replace all JSON objects that contain the $ref property and expand them to their JSON Schema definitions. This seems like it might take some work. I don’t think I would recommend trying it this way.

Another way we could do it is to define our JSON Schemas in external JSON files and then reference them in the RAML like so:

  • facility: !include schemas/facility.json
  • facilityArray: |
  {
      "type": "array",
      "items": { "type": "object", "$ref": "schemas/facility.json" }
  }

That would create a number of extra files, but I haven’t determined a way to reference JSON Schemas in RAML.

Shalom,

Chongsun

– ​

There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongs…@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

On Oct 10, 2016, at 5:53 PM, Paweł Nawrocki <pnaw…@soldevelo.com> wrote:

Hello everybody!

Recently, I was trying to update our raml files by adding response body schemas. This seem to have been already mentioned before on this group, but I guess no one found the way to solve it (https://groups.google.com/forum/#!topic/openlmis-dev/_7GciBqHLfU ). There seems to be a problem with defining “arrays of objects of specified type”. We define a schema like this:

- facilityArray: |
 {
 "type": "array",
 "items": { "type": "object", "$ref":"#/schemas/facility" }

 }
Then, if we put this as a schema for response body, the integration test would fail on following line:


assertThat(RAML_ASSERT_MESSAGE, restAssured.getLastReport(), RamlMatchers.hasNoViolations());

saying, that "the reference schema could not be resolved" (more info in the topic linked above).


I have not found any solution or live example in official raml docs, though I found a post on their official forum with similar issue ([http://forums.raml.org/t/set-body-to-be-array-of-defined-schema-objects/1566](http://forums.raml.org/t/set-body-to-be-array-of-defined-schema-objects/1566)).
From what is suggests, RAML 0.8 does not fully support that kind of declaration, or at least it's related tools do not.


Does anyone know a solution to this issue?


If we can't come up with a solution to this, we may switch to RAML 1.0 (although we might also need to revise if our tools support it), or have some workaround (like defining the above facilityArray as array of objects without referencing schema (so we're losing consistency), or copy-paste facility's definition in place of reference (making redundant declaration) - those two are proven to work).


Best regards,
Paweł

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev…@googlegroups.com.

To post to this group, send email to openl…@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/b42f68cc-9798-4568-b049-172c0b8ba858%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/bb751145-ae30-4fc1-af80-6374a43c91ad%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Hey everyone,

I also forgot to mention that this pattern is documented in our style guide (https://github.com/OpenLMIS/openlmis-template-service/blob/master/STYLE-GUIDE.md).

Shalom,

Chongsun

– ​

There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongsun.ahn@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

···

On Nov 9, 2016, at 4:51 PM, Chongsun Ahn chongsun.ahn@villagereach.org wrote:

Hey everyone,

I have been working on establishing the new pattern of JSON schemas for our RAML (OLMIS-894) for OpenLMIS v3 and have checked in some changes to the RAML in the Reference Data Service. You can see an example of how JSON schema is defined in the RAML (for a right and a rightArray, a list of rights) at the following link:

https://github.com/OpenLMIS/openlmis-referencedata/blob/master/src/main/resources/api-definition.yaml#L254

The actual JSON schema definition for a right is in a separate file at this link:

https://github.com/OpenLMIS/openlmis-referencedata/blob/master/src/main/resources/schemas/right.json

As we make changes to the API definition in the RAML for v3, we should try to follow this pattern in defining JSON schemas. Please let me know if you have any feedback.

Shalom,

Chongsun

– ​

There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongsun.ahn@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

On Oct 24, 2016, at 10:43 AM, Paweł Nawrocki pnawrocki@soldevelo.com wrote:

Hey!

It seems that we keep referencing schemas the wrong way, and it works only because we don’t validate raml in those controller tests.

Schemas are still being references directly, instead of switching to the style you suggested.

I’m curious if we’re leaving this for now as it is, or should we should start enforcing the proper style somehow?

Cheers,

Paweł

W dniu środa, 12 października 2016 14:39:56 UTC+2 użytkownik chongsun.ahn napisał:

Hey Paweł,

From doing some research, it appears that it would be ideal to go to RAML 1.0, since it introduces the idea of something called “data types,” which appears to do what we want in defining JSON schemas. Then we could define our schemas in the more readable RAML format instead of using JSON Schema format. However, our RAML testing tool does not have support for RAML 1.0 yet, and it’s not clear when that support will be implemented.

One way we could do it is try to (via a script or tool) replace all JSON objects that contain the $ref property and expand them to their JSON Schema definitions. This seems like it might take some work. I don’t think I would recommend trying it this way.

Another way we could do it is to define our JSON Schemas in external JSON files and then reference them in the RAML like so:

  • facility: !include schemas/facility.json
  • facilityArray: |
  {
      "type": "array",
      "items": { "type": "object", "$ref": "schemas/facility.json" }
  }

That would create a number of extra files, but I haven’t determined a way to reference JSON Schemas in RAML.

Shalom,

Chongsun

– ​

There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongs…@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

On Oct 10, 2016, at 5:53 PM, Paweł Nawrocki <pnaw…@soldevelo.com> wrote:

Hello everybody!

Recently, I was trying to update our raml files by adding response body schemas. This seem to have been already mentioned before on this group, but I guess no one found the way to solve it (https://groups.google.com/forum/#!topic/openlmis-dev/_7GciBqHLfU ). There seems to be a problem with defining “arrays of objects of specified type”. We define a schema like this:

- facilityArray: |
 {
 "type": "array",
 "items": { "type": "object", "$ref":"#/schemas/facility" }

 }
Then, if we put this as a schema for response body, the integration test would fail on following line:


assertThat(RAML_ASSERT_MESSAGE, restAssured.getLastReport(), RamlMatchers.hasNoViolations());

saying, that "the reference schema could not be resolved" (more info in the topic linked above).


I have not found any solution or live example in official raml docs, though I found a post on their official forum with similar issue ([http://forums.raml.org/t/set-body-to-be-array-of-defined-schema-objects/1566](http://forums.raml.org/t/set-body-to-be-array-of-defined-schema-objects/1566)).
From what is suggests, RAML 0.8 does not fully support that kind of declaration, or at least it's related tools do not.


Does anyone know a solution to this issue?


If we can't come up with a solution to this, we may switch to RAML 1.0 (although we might also need to revise if our tools support it), or have some workaround (like defining the above facilityArray as array of objects without referencing schema (so we're losing consistency), or copy-paste facility's definition in place of reference (making redundant declaration) - those two are proven to work).


Best regards,
Paweł

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev…@googlegroups.com.

To post to this group, send email to openl…@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/b42f68cc-9798-4568-b049-172c0b8ba858%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/bb751145-ae30-4fc1-af80-6374a43c91ad%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/FCB0F27B-C2F5-4686-AE5A-FDBC9E2061F4%40villagereach.org
.

For more options, visit https://groups.google.com/d/optout.